release please
v16.15.0
Release Please は、CHANGELOG の生成、GitHub リリースの作成、プロジェクトのバージョン バンプを自動化します。
これは、git 履歴を解析し、従来のコミット メッセージを探し、リリース PR を作成することによって行われます。
パッケージ マネージャーへの公開や複雑なブランチ管理は処理しません。
release-please は、デフォルトのブランチにランディングされたものを継続的にリリースするのではなく、リリース PR を維持します。
これらのリリース PR は、追加の作業がマージされるにつれて最新の状態に保たれます。リリースにタグを付ける準備ができたら、リリース PR をマージするだけです。スカッシュマージとマージコミットは両方ともリリース PR で機能します。
Release PR がマージされると、release-please は次の手順を実行します。
変更ログ ファイル ( CHANGELOG.mdなど) を他の言語固有のファイル ( package.jsonなど) とともに更新します。
コミットにバージョン番号のタグを付けます
タグに基づいて GitHub リリースを作成します
PR 自体のステータス ラベルによって、リリース PR がライフサイクルのどの位置にあるかがわかります。
autorelease: pendingマージ前のリリース PR の初期状態です。
autorelease: tagged 、リリース PR がマージされ、リリースが GitHub でタグ付けされていることを意味します
autorelease: snapshotスナップショットのバージョンアップのための特別な状態です。
autorelease: published GitHub リリースが Release PR に基づいて公開されたことを意味します ( release-please はこのタグを自動的に追加しませんが、公開ツールの規則としてこれを推奨します)。
「リリースしてください」は、従来のコミット メッセージを使用していることを前提としています。
覚えておくべき最も重要なプレフィックスは次のとおりです。
fix:バグ修正を表し、SemVer パッチに関連付けられます。
feat:新しい機能を表し、SemVer マイナーに関連付けられます。
feat!: 、 fix!: 、 refactor!:など。これらは重大な変更 ( !で示される) を表し、SemVer メジャーになります。
プル リクエストをマージするときは、スカッシュ マージを使用することを強くお勧めします。直線的な Git 履歴により、次のことがはるかに簡単になります。
履歴を追跡 - コミットはマージ日によって並べ替えられ、プル リクエスト間で混合されません。
バグを見つけて元に戻す - git bisectどの変更がバグを引き起こしたかを追跡するのに役立ちます
リリースを制御します - 変更ログを制御してください - PR をマージすると、PR のスコープ内では意味のあるコミット メッセージが含まれる可能性がありますが、メイン ブランチにマージされると意味がありません。たとえば、 feat: introduce feature A 、その後fix: some bugfix introduced in the first commit行うことができます。メイン ブランチではバグが発生したことがないため、 fixコミットは実際にはリリース ノートとは無関係です。
クリーンなメイン ブランチを維持する - レッド/グリーン開発 (コミット A で失敗したテストを作成し、コミット B で修正) とマージ (またはリベース マージ) のようなものを使用する場合、メイン ブランチに特定の時点が存在します。テストが通らないところ。
Release Please では、フッターを使用して 1 つのコミットで複数の変更を表すことができます。
偉業: v4 UUID を暗号化に追加します これにより、v4 UUID のサポートがライブラリに追加されます。 fix(utils): Unicode は例外をスローしなくなりました PiperOrigin-RevId: 345559154 重大な変更: encode メソッドがスローされなくなりました。 ソースリンク: googleapis/googleapis@5e0dcb2 feat(utils): エンコードを更新して Unicode をサポートする PiperOrigin-RevId: 345559182 ソースリンク: googleapis/googleapis@e5eef86
上記のコミット メッセージには次の内容が含まれます。
「v4 UUID を暗号化に追加」機能のエントリ。
「Unicode は例外をスローしなくなった」という修正のエントリと、それが破壊的な変更であるという注記。
「Unicode をサポートするためにエンコードを更新する」機能のエントリ。
メイン ブランチへのコミットのコミット本文にRelease-As: xxx (大文字と小文字は区別されません) が含まれている場合、Release Please は指定されたバージョンの新しいプル リクエストを開きます。
空のコミットの例:
git commit --allow-empty -m "chore: release 2.0.0" -m "Release-As: 2.0.0"実行すると、次のコミット メッセージが表示されます。
雑用: リリース 2.0.0 リリース名: 2.0.0
プル リクエストをマージし、そのコミットのリリース ノートの生成に使用されたコミット メッセージを修正したい場合は、マージされたプル リクエストの本文を編集して、次のようなセクションを追加できます。
BEGIN_COMMIT_OVERRIDE feat: add ability to override merged commit message fix: another message chore: a third message END_COMMIT_OVERRIDE
次回 Release Please を実行すると、マージされたコミット メッセージではなく、そのオーバーライド セクションがコミット メッセージとして使用されます。
Release Please は、デフォルト ブランチに前回のリリース以降の「リリース可能なユニット」が含まれていることを認識した後、リリース プル リクエストを作成します。リリース可能なユニットは、「feat」、「fix」、「deps」のいずれかのプレフィックスが付いたブランチへのコミットです。 (「雑務」または「ビルド」コミットはリリース可能な単位ではありません。)
一部の言語には、特定の解放可能なユニット構成があります。たとえば、「docs」は、Java および Python のリリース可能なユニットの接頭辞です。
autorelease: pendingまたはautorelease: triggeredラベルがないことを確認します。 autorelease: pendingまたはautorelease: triggeredラベルが付いた既存のプル リクエストを確認します。 GitHub API の障害により、以前のリリースでタグが正しく削除されなかった可能性があり、Release Please は以前のリリースがまだ保留中であると判断します。保留中のリリースがないことが確実な場合は、 autorelease: pendingまたはautorelease: triggeredラベルを削除します。
GitHub アプリケーション ユーザーの場合、 autorelease: pendingというラベルが付いた既存のプル リクエストがある場合、Release Please は新しいプル リクエストを作成しません。このケースを確認するには、このラベルを持つプル リクエストを検索します。 (最新のリリース プル リクエストである可能性が非常に高いです。) ラベルが含まれるリリース プル リクエストが見つかり、それがリリースされる予定がない (またはすでにリリースされている) 場合は、 autorelease: pendingラベルを削除して、Release Please を再実行します。
リリース可能なユニットを含むプル リクエストがマージされた後、Release Please がリリース PR の作成を怠ったと思われる場合は、 release-pleaseを再実行してください。 GitHub アプリケーションを使用している場合は、マージされたプル リクエストにrelease-please:force-runラベルを追加します。このアクションを使用している場合は、失敗した呼び出しを探して、ワークフローの実行を再試行します。 「Release Please」はプル リクエストをすぐに処理して、リリース可能なユニットを見つけます。
Release Please は、次の種類のリポジトリのリリースを自動化します。
| リリースタイプ | 説明 |
|---|---|
bazel | Bazel モジュール (MODULE.bazel と CHANGELOG.md を含む) |
dart | pubspec.yaml と CHANGELOG.md を含むリポジトリ |
elixir | mix.exs と CHANGELOG.md を含むリポジトリ |
go | CHANGELOG.md のあるリポジトリ |
helm | Chart.yaml と CHANGELOG.md を含むリポジトリ |
java | リリースごとにスナップショット バージョンを生成する戦略 |
krm-blueprint | 1 つ以上の KRM ファイルと CHANGELOG.md を含む kpt パッケージ |
maven | Maven プロジェクトの戦略。リリースごとにスナップショット バージョンを生成し、 pom.xml自動的に更新します。 |
node | package.json と CHANGELOG.md を含む Node.js リポジトリ |
expo | Expo ベースの React Native リポジトリ (package.json、app.json、CHANGELOG.md を含む) |
ocaml | 1 つ以上の opam または esy ファイルと CHANGELOG.md を含む OCaml リポジトリ |
php | Composer.json と CHANGELOG.md を含むリポジトリ |
python | Python リポジトリ (setup.py、setup.cfg、CHANGELOG.md、オプションで pyproject.toml と <project>/__init__.py) |
ruby | version.rb と CHANGELOG.md を含むリポジトリ |
rust | Cargo.toml (クレートまたはワークスペースとして。ただし、ワークスペースにはマニフェスト主導のリリースと「cargo-workspace」プラグインが必要であることに注意してください) と CHANGELOG.md を備えた Rust リポジトリ |
sfdx | sfdx-project.json と CHANGELOG.md を含むリポジトリ |
simple | version.txt と CHANGELOG.md を含むリポジトリ |
terraform-module | terraform モジュール (バージョンは README.md と CHANGELOG.md にあります) |
release-please をデプロイするにはさまざまな方法があります。
Release Please を実行する最も簡単な方法は、GitHub アクションとして実行することです。インストールと構成の手順については、googleapis/release-please-action を参照してください。
すべての設定オプションについては、「release-please CLI の実行」を参照してください。
Release Please を GitHub アプリとしてデプロイできるプロボット アプリケーションが利用可能です。インストールと構成の手順については、github.com/googleapis/repo-automation-bots を参照してください。
「Release Please」は、最後のリリースタグ以降のコミットを調べます。以前のリリースが見つからない場合もあります。リポジトリをオンボードする最も簡単な方法は、マニフェスト構成をブートストラップすることです。
Release Please には、リリース プロセスをカスタマイズできるようにするためのいくつかの構成オプションが用意されています。詳細については、customizing.md を参照してください。
Release Please は、同じリポジトリからの複数のアーティファクトのリリースもサポートしています。詳細については、manifest-releaser.md を参照してください。
当社のクライアント ライブラリは、Node.js リリース スケジュールに従います。ライブラリは、Node.js の現在のアクティブバージョンとメンテナンスバージョンのすべてと互換性があります。
Node.js の一部のサポート終了バージョンを対象としたクライアント ライブラリが利用可能で、npm dist-tags 経由でインストールできます。 dist-tag は、 legacy-(version)という命名規則に従います。
従来の Node.js バージョンはベスト エフォートとしてサポートされています。
レガシー バージョンは継続的統合ではテストされません。
一部のセキュリティ パッチはバックポートできない場合があります。
依存関係は最新に保たれず、機能はバックポートされません。
legacy-8 : Node.js 8 と互換性のあるバージョンのクライアント ライブラリをこの dist タグからインストールします。
このライブラリはセマンティック バージョニングに従っています。
貢献は大歓迎です! 「貢献ガイド」を参照してください。
ライブラリの設計の詳細については、「設計」を参照してください。
一般的な問題と構成のトラブルシューティングについては、「トラブルシューティング」を参照してください。
Apache バージョン 2.0
ライセンスを参照
これは Google の公式製品ではありません。
