Sorties

Les Release flux de travail commence quand un mainteneur pousse un v* tag. Il n'y a pas de relâchement automatique sur les pousses ordinaires de branche ou les requêtes de traction.

Version du contrat

Utilisez des balises canoniques comme v0.1.0 ou v0.1.0-rc.1. La version de l'application et Docker version tag omit le leader v. Composants numériques de premier plan, espace blanc, caractères shell et SemVer construire des métadonnées (+...) sont rejetés avant publication. Les identifiants numériques de prépublication doivent également être canoniques.

Chaque version comprend :

• sublane_VERSION_linux_amd64.tar.gz et sublane_VERSION_linux_arm64.tar.gz.
• docker.compose.yaml et SHA256SUMS pour les dossiers de diffusion publique.
• Une multiplateforme ghcr.io/murongg/sublane:VERSION image, plus les deux étiquettes d'architecture.
• Conservez une note de version Changelog générée à partir de l'historique Git avec git-cliff 2.14.2.

Seule la balise de version stable la plus élevée actuellement présente dans le dépôt peut mettre à jour la Docker latest canal et GitHub's la dernière version de la désignation. Une pré-version ou une version de maintenance plus ancienne ne déplace jamais ces canaux vers l'arrière. Si la construction de la balise stable la plus élevée échoue, rediriger cette version; les balises inférieures ne prennent pas sa place intentionnellement. latest.

Configuration du dépôt pour la première fois

Le flux de travail utilise GITHUB_TOKEN, dont l'objet est contents: write et packages: write Il n'a pas besoin d'un Docker Compte Hub ou jeton d'accès personnel. GitHub Les actions et la publication des paquets du GHCR doivent être autorisées par la politique du dépôt/organisation. Toutes les dépendances d'action sont liées à des SHA de commit complet.

L'étiquette source du dépôt lie l'image au dépôt. Les paquets GHCR peuvent d'abord être privés même pour un dépôt source public. Après la première publication réussie, vérifiez les paramètres d'accès du paquet et le rendre public si des tirages anonymes sont prévus. Voir GitHub's Documents relatifs au registre des conteneurs. Gardez les paquets publiés associés à ce dépôt afin que les flux de travail ultérieurs conservent l'accès à l'écriture.

Publier une version

Générer et examiner CHANGELOG.md sur votre branche développement avec make changelog, puis le commit avec la documentation faisant face à la libération. Fusionner ces changements et le flux de travail de la libération d'abord, et exécuter make check. Choisissez une nouvelle version inutilisée; ne déplacez pas une balise de sortie existante.

Par exemple, après avoir choisi v0.1.0:

git switch main
git pull --ff-only
make publish-check TAG=v0.1.0
make publish TAG=v0.1.0

make publish-check exécute le même prévol sans créer ou pousser une balise. make publish crée une balise annotée au commit inspecté et pousse seulement cette balise. Les deux nécessitent un arbre de travail propre (y compris les fichiers non traqués), main branche, un workflow de publication existant dans ce commit, et exactement un origin destination de poussée dont main Les balises locales ou distantes dupliquées sont rejetées. Aucune branche n'est commutée, fusionnée ou poussée automatiquement.

La balise détermine le type de libération; aucun drapeau de pré-liberté distinct n'est nécessaire :

make publish TAG=v0.1.0-rc.1

Vous pouvez aussi courir node scripts/publish.mjs v0.1.0 --dry-run ou node scripts/publish.mjs v0.1.0 Node.js 24 et Git sont nécessaires, avec des identifiants de poussée Git fonctionnant (par exemple un agent SSH); Docker Les identifiants Hub ne sont pas requis. Le script vérifie la balise distante après avoir poussé et imprimé la GitHub Actions lien de workflow lorsque la télécommande configurée utilise un reconnu GitHub URL.

Si un push échoue ou que son résultat ne peut pas être vérifié, la balise locale est conservée parce que la télécommande peut déjà l'avoir acceptée. Inspectez la télécommande et Actions d'abord. Si la balise distante est absente, utilisez la commande de réessayer un seul tag imprimée par le script. Elle ne supprime jamais les balises ou les poussées de force. Le script déclenche le pipeline CI existant; il ne signale pas les constructions ou la publication comme étant terminées simplement parce que le push du tag a réussi.

Publier une version choisie à la fois et inspecter le résultat Actions avant d'annoncer la disponibilité. Pousser une balise de version est le déclencheur de publication; le flux de travail crée la GitHub Libérez-vous.

Séquence du flux de travail

1. Valider la balise et calculer le chemin d'image GHCR minuscule à partir du nom du dépôt.
2. Appeler le flux de travail normal de l'IC: sqlc drive check, Go race test/vet, frontend checks/build, release metadonnées tests et Compose validation.
3. Construire et tester la fumée Docker Sur les PR et les versions, extraire le binaire réel de chaque image testée, le paqueter avec des fichiers de déploiement et des avis de licence, puis le décompresser et l'exécuter pour vérifier la version. Release exécute également enregistrer les deux images testées comme des artefacts Actions de courte durée.
4. Après toutes les vérifications passe, récupérer l'historique complet étiqueté, générer des notes de libération avec cliff.toml, et créer ou reprendre un projet GitHub Release. Les notes provisoires sont régénérées en réessayer; une version publiée antérieurement n'est jamais écrasée.
5. Chargez et poussez les images testées, puis créez la balise de version multi-plateforme. Aucune deuxième construction d'application ne se produit pendant la publication.
6. Télécharger des archives binaires, Compose et SHA-256 checksums. Promouvoir le nouveau canal stable quand admissible, puis publier la version terminée.

Les étiquettes version/source/révision sont intégrées dans l'image et sublane --version Les systèmes de fichiers racine d'image ne contiennent que des utilitaires Alpine runtime, des certificats CA publics, les avis binaires et de licence. Aucune commande source, compilateur, dépendances Node.js ou données locales n'est incluse.

Défauts et rétractations

Utilisation Réouverture d'emplois échoués avant la fin, les artefacts de publication restent dans un brouillon et peuvent être remplacés par une ré-essai. Des images par architecture/version peuvent déjà exister si une étape ultérieure a échoué; la ré-essai complète la même version. GitHub La mainlevée ne peut pas être une transaction atomique, alors vérifiez les deux destinations après un échec.

Les artefacts sont conservés pendant sept jours. Après l'expiration, rediriger tous les travaux pour les reconstruire et les tester à nouveau. GitHub Une fois qu'une version est publiée, utilisez une nouvelle version pour corriger le code ou l'emballage plutôt que de l'écraser. La suppression ou le déplacement d'une balise ne retourne pas les binaires téléchargés, les images publiées ou les bases de données déployées.

GITHUB_TOKEN-created tag pousse normalement ne déclenche pas un autre workflow. Si une autre automatisation crée des tags, utilisez une portée appropriée GitHub Appliquez ou déclenchez la libération par un flux d'expédition explicitement conçu. Le mainteneur manuel pousse le travail sans cette configuration supplémentaire. Voir GitHub's règles de déclenchement du flux de travail.

Emballage local

make release VERSION=0.0.0-test

Cela construit la façade une fois, compile les deux binaires Linux et écrit des archives plus SHA256SUMS sous ignoré dist/release/. Les archives existantes ne sont pas écrasées; utilisez une nouvelle version de test ou déplacez les artefacts générés avant de reconstruire. Cette commande ne pousse pas les images ou crée des versions.

Génération du changement de registre

Installer git-cliff 2.14.2 (la version épinglée dans CI). Il s'agit d'un outil de développement, pas une dépendance du serveur. Par exemple, avec Rust installé, utiliser cargo install git-cliff --locked --version 2.14.2. Un exécutable téléchargé peut être sélectionné à travers GIT_CLIFF=/path/to/git-cliff.

make changelog
make changelog-check

cliff.toml Les caractéristiques et les corrections suivent les Commits conventionnels; les constructions, les performances et les refacteurs sont modifiés. Les déprécations/suppressions explicites et les changements de champ de sécurité obtiennent leurs propres sections. Les docs, tests, style et corvées routiniers sont omis, tout en brisant les changements et leurs explications restent visibles. Fusionner les messages et les commits non conventionnels sont exclus; examiner le texte généré avant la publication.

Generation lit l'historique Git local avec des métadonnées réseau et des commandes de gabarit externes désactivées. CHANGELOG.md seulement après le rendu réussit, et ne crée pas de balises, de versions de changement ou de fichiers de commit. Commettez le fichier généré par le flux PR normal avant de lancer make publish, qui nécessite toujours une main synchronisée propre. Les changements de dépôts comprennent des sections de pré-release; les notes de publication stables résument l'ensemble du cycle depuis la balise stable précédente, y compris les changements introduits dans les pré-releases.

Pour une balise existante, cochez HEAD:

make release-notes TAG=v0.1.0

Ceci écrit dist/release-notes.md utilisant le même modèle; le flux de travail de libération installe le générateur épinglé, récupère l'historique complet et passe ce fichier à GitHub. Une étiquette manquante ou mal assortie est rejetée. L'IC exécute des tests d'intégration de l'histoire synthétique; make changelog-check localement pour activer ces tests lorsque git-cliff est installé. make check les garde facultatifs à moins SUBLANE_TEST_CHANGELOG=1 Aucune commande ne modifie le README.