リリース | SubLane

の Release ワークフローは、メンテナがプッシュすると開始されます。 v* タグ。通常のブランチのプッシュまたはプルリクエストには自動リリースはありません。

バージョン契約

次のような正規タグを使用します。 v0.1.0 または v0.1.0-rc.1。アプリケーションのバージョンと Docker バージョンタグは先頭を省略します。 v。先頭のゼロの数値コンポーネント、空白、シェル文字、および SemVer ビルドメタデータ (+...) は公開前に拒否されます。プレリリースの数値識別子も正規のものである必要があります。

すべてのリリースには次のものが含まれます。

sublane_VERSION_linux_amd64.tar.gz そして sublane_VERSION_linux_arm64.tar.gz.
docker.compose.yaml そして SHA256SUMS 公開リリースファイル用。
マルチプラットフォーム ghcr.io/murongg/sublane:VERSION 画像と 2 つのアーキテクチャタグを追加します。
固定された git-cliff 2.14.2 を使用して、Git 履歴から生成された変更ログリリースノートを保存します。

Docker を更新できるのは、現在リポジトリに存在する最も安定したバージョンのタグのみです。 latest チャンネルと GitHub の最新リリースの指定。プレリリースまたは古いメンテナンスバージョンによって、これらのチャネルが後方に移動されることはありません。最も安定したタグのビルドが失敗した場合は、そのリリースを再実行します。下位のタグは意図的にその位置を占めません。デプロイメントでは、バージョンまたはダイジェストに依存するのではなく、バージョンまたはダイジェストを固定する必要があります。 latest.

初回のリポジトリ設定

ワークフローで使用されるのは、 GITHUB_TOKEN、範囲は次のとおりです contents: write そして packages: write 出版の仕事のみ。 Docker Hub アカウントや個人のアクセストークンは必要ありません。 GitHub アクションと GHCR パッケージの公開は、リポジトリ/組織ポリシーによって許可される必要があります。すべてのアクションの依存関係はフルコミット SHA に固定されます。

リポジトリソースラベルは、イメージをリポジトリにリンクします。 GHCR パッケージは、パブリックソースリポジトリであっても、最初はプライベートにすることができます。最初の公開が成功した後、パッケージのアクセス設定を確認し、匿名プルが目的の場合はパッケージを公開します。 GitHub を参照コンテナレジストリのドキュメント。公開されたパッケージをこのリポジトリに関連付けたままにして、後続のワークフローが書き込みアクセスを保持できるようにします。

バージョンを公開する

生成してレビューする CHANGELOG.md 開発ブランチ上で make changelogを作成し、リリース向けドキュメントを使用してコミットします。まずこれらの変更とリリースワークフローをマージして、実行します。 make check。新しい未使用のバージョンを選択してください。既存のリリースタグを移動しないでください。

たとえば、選択した後、 v0.1.0:

Publish a version · 1

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

make publish-check タグを作成またはプッシュせずに同じプリフライトを実行します。 make publish 検査されたコミットで注釈付きのタグを作成し、そのタグのみをプッシュします。どちらもクリーンな作業ツリー (追跡されていないファイルを含む) を必要とします。 main ブランチ、そのコミット内の既存のリリースワークフロー、および 1 つだけ origin プッシュ宛先 main ローカルの HEAD と一致します。ローカルまたはリモートの重複タグは拒否されます。ブランチは自動的に切り替え、マージ、プッシュされません。

タグはリリースのタイプを決定します。個別のプレリリースフラグは必要ありません。

Publish a version · 2

make publish TAG=v0.1.0-rc.1

実行することもできます node scripts/publish.mjs v0.1.0 --dry-run または node scripts/publish.mjs v0.1.0 リポジトリから直接。 Node.js 24 と Git が必要で、動作する Git プッシュ認証情報 (SSH エージェントなど) が必要です。 Docker ハブの認証情報は必要ありません。スクリプトは、プッシュ後にリモートタグを検証し、設定されたリモートが認識された GitHub URL を使用する場合、GitHub アクションワークフローリンクを出力します。

プッシュが失敗した場合、またはその結果を検証できない場合、リモートがすでにローカルタグを受け入れている可能性があるため、ローカルタグは保持されます。まずリモコンとアクションを調べてください。リモートタグが存在しない場合は、スクリプトによって出力される単一タグの再試行コマンドを使用します。タグを削除したり、強制的にプッシュしたりすることはありません。スクリプトは既存の CI パイプラインをトリガーします。タグのプッシュが成功したからといって、ビルドや公開が完了したとは報告しません。

サンプルバージョンは説明のためのものです。選択したバージョンを一度に 1 つずつ公開し、可用性を発表する前にアクションの結果を検査します。バージョンタグのプッシュが公開のトリガーとなります。ワークフローは GitHub リリース自体を作成します。

ワークフローのシーケンス

タグを検証し、リポジトリ名から小文字の GHCR イメージパスを計算します。
通常の CI ワークフローを呼び出します: SQL ドリフトチェック、Go レーステスト/vet、フロントエンドチェック/ビルド、リリースメタデータテスト、および Compose 検証。
ネイティブ Linux amd64 および arm64 ランナーで Docker イメージをビルドしてスモークテストします。 PR およびリリースでは、テストされた各イメージから実際のバイナリを抽出し、展開ファイルおよびライセンス通知とともにパッケージ化し、解凍して実行してバージョンを確認します。リリースの実行では、テストされた両方のイメージが短期間のアクションアーティファクトとして保存されます。
すべてのチェックに合格したら、タグ付けされた完全な履歴を取得し、次のコマンドでリリースノートを生成します。 cliff.toml、ドラフト GitHub リリースを作成または再開します。ドラフトノートは再試行時に再生成されます。以前に公開されたリリースが上書きされることはありません。
これらのテスト済みイメージをロードしてプッシュし、マルチプラットフォームバージョンタグを作成します。公開中に 2 回目のアプリケーションのビルドは行われません。
バイナリアーカイブ、Compose、および SHA-256 チェックサムをアップロードします。資格がある場合は最新の安定したチャネルを宣伝し、完成したリリースを公開します。

バージョン/ソース/リビジョンのラベルが画像に埋め込まれており、 sublane --version パッケージ版をレポートします。イメージルートファイルシステムには、Alpine ランタイムユーティリティ、パブリック CA 証明書、バイナリおよびライセンス通知のみが含まれます。ソースのチェックアウト、コンパイラ、Node.js の依存関係、ローカルデータは含まれません。ビルドコンテキストのホワイトリストには、ローカルデータベース、暗号化キー、バックアップ、ワークツリーが除外されます。

失敗と再試行

使用 失敗したジョブを再実行する ネットワーク、ビルド、またはレジストリ操作が失敗したときに、同じタグのワークフローが実行されます。完了するまで、リリースアーティファクトはドラフトに残り、再試行によって置き換えることができます。後のステップが失敗した場合、アーキテクチャ/バージョンごとのイメージがすでに存在している可能性があります。再試行により同じリリースが完了します。レジストリの公開と GitHub Release を 1 つのアトミックトランザクションにすることはできないため、失敗後に両方の宛先を確認してください。

アーティファクトは 7 日間保持されます。期限が切れたら、すべてのジョブを再実行して再構築し、再テストします。再実行では、その実行内の同じ名前のアクションアーティファクトが置き換えられます。すでに公開されている GitHub リリースは保護されたままです。リリースが公開されたら、上書きするのではなく、コードまたはパッケージの修正に新しいバージョンを使用してください。タグを削除または移動しても、ダウンロードされたバイナリ、公開されたイメージ、またはデプロイされたデータベースはロールバックされません。

GITHUB_TOKEN-created タグのプッシュは通常、別のワークフローをトリガーしません。別のオートメーションがタグを作成する場合は、適切にスコープされた GitHub アプリ/トークンを使用するか、明示的に設計されたディスパッチフローを通じてリリースをトリガーします。手動のメンテナは、追加のセットアップなしで作業をプッシュします。 GitHub を参照ワークフロートリガールール.

現地梱包

Local packaging · 3

make release VERSION=0.0.0-test

これにより、フロントエンドが一度ビルドされ、2 つの Linux バイナリがクロスコンパイルされ、アーカイブと SHA256SUMS 無視されました dist/release/。既存のアーカイブは上書きされません。新しいテストバージョンを使用するか、再構築する前に以前に生成されたアーティファクトを移動してください。このコマンドは、イメージのプッシュやリリースの作成を行いません。ローカルビルドの検証をネイティブコンテナーの実行時の証拠から切り離してください。

変更ログの生成

インストール git-cliff 2.14.2 (CI に固定されているバージョン)。これは開発ツールであり、サーバーに依存するものではありません。たとえば、Rust がインストールされている場合は、次のようにします。 cargo install git-cliff --locked --version 2.14.2。ダウンロードされた実行可能ファイルは、次の方法で選択できます。 GIT_CLIFF=/path/to/git-cliff.

Changelog generation · 4

make changelog
make changelog-check

cliff.toml 変更ログの見出しを使用します: 追加、変更、非推奨、削除、修正、セキュリティ。機能と修正は従来のコミットに従います。ビルド、パフォーマンス、リファクタリングが変更されました。明示的な非推奨/削除およびセキュリティを対象とした変更には、独自のセクションが用意されています。日常的なドキュメント、テスト、スタイル、雑務は省略されていますが、重大な変更とその説明は表示されたままです。マージメッセージと非従来型のコミットは除外されます。リリース前に生成されたテキストを確認してください。

生成では、ネットワークメタデータと外部テンプレートコマンドが無効になったローカル Git 履歴が読み取られます。置き換えます CHANGELOG.md レンダリングが成功した後にのみ実行され、タグの作成、バージョンの変更、ファイルのコミットは行われません。実行前に、通常の PR フローを通じて生成されたファイルをコミットします。 make publishただし、クリーンな同期メインが必要です。リポジトリの変更ログにはプレリリースセクションが含まれています。安定版リリースノートには、プレリリースで最初に導入された変更を含む、前の安定版タグ以降のサイクル全体が要約されています。

HEAD でチェックアウトされた既存のタグの場合:

Changelog generation · 5

make release-notes TAG=v0.1.0

これは書きます dist/release-notes.md 同じテンプレートを使用します。リリースワークフローでは、固定されたジェネレーターをインストールし、完全な履歴を取得して、このファイルを GitHub に渡します。タグが欠落しているか不一致である場合は拒否されます。 CI は合成履歴統合テストを実行します。走る make changelog-check git-cliff のインストール時にこれらのテストをローカルで有効にします。普通 make check そうでない限り、それらはオプションのままにしておきます SUBLANE_TEST_CHANGELOG=1 が設定されています。どちらのコマンドでも README は変更されません。