Freisetzungen

Die Release Workflow beginnt, wenn ein Maintainer eine v* Es gibt keine automatische Freigabe bei gewöhnlichen Branch-Pushes oder Pull-Requests.

Versionsvertrag

Verwenden Sie kanonische Tags wie v0.1.0 oder v0.1.0-rc.1. Die Anwendungsversion und Docker Versions-Tag lässt die führende v. Führende numerische Komponenten, Whitespace, Shell-Zeichen und SemVer-Bau-Metadaten ()+...) vor der Veröffentlichung abgelehnt werden. numerische Vorabkennungen müssen ebenfalls kanonisch sein.

Jedes Release beinhaltet:

• sublane_VERSION_linux_amd64.tar.gz und sublane_VERSION_linux_arm64.tar.gz.
• docker.compose.yaml und SHA256SUMS für die Public Release Files.
• Eine Multiplattform ghcr.io/murongg/sublane:VERSION Bild, plus die beiden Architektur-Tags.
• Halten Sie eine Changelog-Release-Notizen, die aus der Git-Historie mit gepinntem Git-Cliff 2.14.2 generiert wurden.

Nur das höchste stabile Versions-Tag, das derzeit im Repository vorhanden ist, kann das Update Docker latest Kanal und GitHub's latest-release-Bezeichnung. Eine Vorabversion oder eine ältere Wartungsversion verschiebt diese Kanäle niemals rückwärts. Wenn der Build des höchst stabilen Tags fehlschlägt, führen Sie diese Version erneut aus. Niedrigere Tags treten absichtlich nicht an ihre Stelle. Bereitstellungen sollten eine Version anheften oder verdauen, anstatt sich darauf zu verlassen latest.

Erstmalige Einrichtung des Repository

Der Workflow nutzt GITHUB_TOKEN, in den Anwendungsbereich von contents: write und packages: write Nur im Publikationsjob. es braucht keine Docker Hub-Konto oder ein persönliches Zugangstoken. GitHub Aktionen und Veröffentlichung von GHCR-Paketen müssen durch die Repository-/Organisationsrichtlinie erlaubt sein. Alle Aktionsabhängigkeiten sind an vollständige Commit-SHAs gebunden.

Das Repository-Quelllabel verbindet das Bild mit dem Repository. GHCR-Pakete können zunächst auch für ein Public-Source-Repository privat sein. Nach der ersten erfolgreichen Veröffentlichung überprüfen Sie die Zugriffseinstellungen des Pakets und machen es öffentlich, wenn anonyme Pulls beabsichtigt sind. GitHub's ContainerregistrierungsunterlagenVeröffentlichte Pakete, die diesem Repository zugeordnet sind, so dass nachfolgende Workflows den Schreibzugriff beibehalten.

Veröffentlichen einer Version

Generieren und Review CHANGELOG.md in Ihrem Entwicklungszweig mit make changelog, dann mit der Dokumentation zur Veröffentlichung festlegen, diese Änderungen und den Workflow zur Veröffentlichung zuerst zusammenführen und ausführen make checkWählen Sie eine neue unbenutzte Version aus; verschieben Sie kein vorhandenes Release-Tag.

Zum Beispiel nach der Auswahl 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 führt den gleichen Preflight aus, ohne einen Tag zu erstellen oder zu drücken. make publish Erstellt einen kommentierten Tag beim inspizierten Commit und drückt nur diesen Tag. main Branch, ein vorhandener Release-Workflow in diesem Commit und genau einer origin Push-Ziel, dessen main Lokale oder entfernte Duplikat-Tags werden abgelehnt, kein Branch wird automatisch geschaltet, zusammengeführt oder gedrückt.

Das Tag bestimmt den Release-Typ; es wird kein separates Pre-Release-Flag benötigt:

make publish TAG=v0.1.0-rc.1

Sie können auch laufen node scripts/publish.mjs v0.1.0 --dry-run oder node scripts/publish.mjs v0.1.0 Node.js 24 und Git sind erforderlich, mit funktionierenden Git-Push-Anmeldeinformationen (z. B. einem SSH-Agenten); Docker Hub-Anmeldeinformationen sind nicht erforderlich. Das Skript überprüft das Remote-Tag nach dem Drücken und druckt die GitHub Workflow-Verknüpfung von Aktionen, wenn die konfigurierte Fernbedienung eine erkannte GitHub URL.

Wenn ein Push fehlschlägt oder sein Ergebnis nicht verifiziert werden kann, wird das lokale Tag beibehalten, weil die Fernbedienung es möglicherweise bereits akzeptiert hat. Überprüfen Sie die Fernbedienung und Aktionen zuerst. Wenn das Remote-Tag abwesend ist, verwenden Sie den Befehl Single-Tag Retry, der vom Skript gedruckt wird. Es löscht niemals Tags oder Force-Pushes. Das Skript löst die vorhandene CI-Pipeline aus. Es meldet Builds oder Veröffentlichung nicht als vollständig, nur weil der Tag-Push erfolgreich war.

Die Beispielversion ist illustrativ. Veröffentlichen Sie jeweils eine ausgewählte Version und prüfen Sie das Ergebnis der Aktionen, bevor Sie die Verfügbarkeit bekannt geben. Das Drücken eines Versions-Tags ist der Auslöser für die Veröffentlichung; der Workflow erstellt die GitHub Befreie dich selbst.

Workflowsequenz

1. Validieren Sie das Tag und berechnen Sie den kleinen GHCR-Bildpfad aus dem Repository-Namen.
2. Rufen Sie den normalen CI-Workflow auf: sqlc drift check, Go race tests/vet, frontend checks/build, release metadaten tests und Compose Validierung.
3. Bauen und Rauchtesten Docker Bild auf nativen Linux amd64- und arm64-Läufern. Auf PRs und Releases extrahieren Sie die eigentliche Binärdatei aus jedem getesteten Bild, verpacken Sie es mit Bereitstellungsdateien und Lizenzhinweisen, entpacken und führen Sie es aus, um die Version zu überprüfen. Release-Läufe speichern auch beide getesteten Bilder als kurzlebige Aktionen Artefakte.
4. Nachdem alle Prüfungen bestanden haben, holen Sie die vollständige markierte Historie ab, erzeugen Sie Release Notes mit cliff.toml, und erstellen oder einen Entwurf wieder aufnehmen GitHub Notes werden beim erneuten Versuch regeneriert; eine zuvor veröffentlichte Version wird nie überschrieben.
5. Laden und drücken Sie diese getesteten Bilder und erstellen Sie dann das Multi-Plattform-Versions-Tag.
6. Binärarchive hochladen, Compose und SHA-256 Prüfsummen. Bewerben Sie den neuesten stabilen Kanal, wenn Sie berechtigt sind, und veröffentlichen Sie dann die abgeschlossene Version.

Versions-/Source-/Revisionslabels sind in das Bild eingebettet und sublane --version Bild-Root-Dateisysteme enthalten nur Alpine Runtime Utilities, Public CA-Zertifikate, die Binär- und Lizenzhinweise. Keine Quellauscheckung, Compiler, Node.js-Abhängigkeiten oder lokale Daten sind enthalten. Build Context Allowlisting schließt lokale Datenbanken, Verschlüsselungsschlüssel, Backups und Worktrees aus.

Ausfälle und Wiederholungen

Verwendung Re-Run gescheiterte Jobs Wenn ein Netzwerk-, Build- oder Registry-Vorgang fehlschlägt, bleiben Release-Artefakte in einem Entwurf und können durch einen Wiederholungsversuch ersetzt werden. Per-Architektur-/Versionsbilder können bereits vorhanden sein, wenn ein späterer Schritt fehlgeschlagen ist; der Wiederholungsversuch vervollständigt den gleichen Release. GitHub Release kann nicht eine atomare Transaktion sein, also überprüfen Sie beide Ziele nach einem Fehler.

Nach dem Ablauf werden alle Jobs wiederholt, um sie zu rekonstruieren und erneut zu testen Reruns ersetzen gleichnamige Aktionen Artefakte in diesem Lauf; bereits veröffentlicht GitHub Releases bleiben geschützt. Sobald ein Release veröffentlicht wurde, verwenden Sie eine neue Version für Code- oder Verpackungskorrekturen, anstatt sie zu überschreiben. Das Löschen oder Verschieben eines Tags führt nicht dazu, dass heruntergeladene Binärdateien, veröffentlichte Bilder oder bereitgestellte Datenbanken zurückgesetzt werden.

GITHUB_TOKEN-erstellte Tag-Pushs lösen normalerweise keinen anderen Workflow aus. GitHub App/Token oder Auslösen der Freigabe durch einen explizit gestalteten Versandfluss. Manueller Maintainer schiebt die Arbeit ohne diese zusätzliche Einrichtung. GitHub's Workflow-Trigger-Regeln.

Lokale Verpackung

make release VERSION=0.0.0-test

Dies baut das Frontend einmal, kreuzkompiliert die beiden Linux-Binärdateien und schreibt Archive plus SHA256SUMS Unter ignoriert dist/release/. Vorhandene Archive werden nicht überschrieben; eine neue Testversion verwenden oder zuvor generierte Artefakte vor dem Neuaufbau verschieben. Dieser Befehl führt nicht zum Schieben von Bildern oder zum Erstellen von Veröffentlichungen. Lokale Build-Validierung von nativen Container-Laufzeitnachweisen trennen.

Changelog Generation

Installieren Git-Cliff 2.14.2 (die in CI angeheftete Version): Es handelt sich um ein Entwicklungstool, nicht um eine Serverabhängigkeit, z. B. mit installiertem Rust, cargo install git-cliff --locked --version 2.14.2Eine heruntergeladene ausführbare Datei kann durch GIT_CLIFF=/path/to/git-cliff.

make changelog
make changelog-check

cliff.toml verwendet Keep a Changelog Überschriften: Added, Changed, Deprecated, Removed, Fixed and Security. Features and Fixes follow Conventional Commits; Builds, Performance and Refactors are Changed. Explicit deprecations/removals and security-scoped changes get their own sections. Routine-Dokumente, Tests, Style und Hausarbeiten werden weggelassen, während brechende Änderungen und ihre Erklärungen sichtbar bleiben. Merge messages and non-conventional commits are excluded; Review the generated text before release.

Generation liest lokale Git-Historie mit Netzwerk-Metadaten und externen Template-Befehlen deaktiviert. CHANGELOG.md Nur wenn das Rendern erfolgreich ist und keine Tags erstellt, Versionen ändert oder Dateien überträgt. make publishRepository Changelogs enthalten Pre-Release-Abschnitte; Stable Release Notes fassen den gesamten Zyklus seit dem vorhergehenden Stable-Tag zusammen, einschließlich der Änderungen, die zuerst in Pre-Releases eingeführt wurden.

Für ein bestehendes Tag, das bei HEAD ausgecheckt wurde:

make release-notes TAG=v0.1.0

Das schreibt dist/release-notes.md mit der gleichen Vorlage; der Release-Workflow installiert den gepinnten Generator, holt den gesamten Verlauf ab und übergibt diese Datei an GitHub. Ein fehlendes oder nicht übereinstimmendes Kennzeichen wird abgelehnt. CI führt Integrationstests zur Synthesegeschichte durch; make changelog-check lokal, um diese Tests zu ermöglichen, wenn git-cliff installiert ist. make check hält sie optional, außer SUBLANE_TEST_CHANGELOG=1 ist gesetzt. Kein Befehl ändert die README.