ship-it

リリースする

完全なリリース依頼では、変更をコミットしてプッシュし、レビュー準備完了のプルリクエストを作成し、CI をすべて成功させて完了してください。新しい PR はドラフトではない状態で作成し、CI の実行中に、リポジトリで必須とされているレビューとローカル検証を完了してください。

依頼の範囲が限定されている場合は、その範囲を守ってください。CI のみの修正では、PR を作成したり、ドラフト／レビュー準備完了の状態、ベース、タイトル、無関係な内容を変更したりせず、該当するブランチとチェックを修正してください。監視のみの依頼では、修正は行わず結果を報告してください。ドラフトのままにするという明示的な依頼は、完全なワークフローより優先されます。

依頼されない限り、PR をマージしないでください。作業を一時停止するのは、重大な曖昧さ、必須の承認、または利用可能なアクセスでは解決できないブロッカーがある場合に限ります。

依頼された作業をコミットする

デフォルトブランチではなく、フィーチャーブランチで作業してください。変更を含む現在のフィーチャーブランチがある場合はそのまま使用し、それ以外の場合はリポジトリの命名規則に従ってください。命名規則がない場合は agent/ を使用してください。

差分と作業ツリーを確認してください。無関係なユーザー変更は保持し、明示したパスをステージしてください。関連するファイルは論理的な単位でコミットにまとめてください。

命令形の件名を使用してください。件名から明らかでない場合は、変更の理由を説明してください。有効な帰属表示と句読点の指示に従ってください。コミット本文は約 80 文字幅で折り返してください。ただし、PR の段落は手動で折り返さないでください。

PR を作成または再利用する

完全なリリース依頼では、プッシュして既存の PR がないか確認してください。

gh pr list --state open --head <branch> --json number,title,url,isDraft,baseRefName,headRefName

既存の PR があれば再利用してください。ドラフトの場合、ユーザーがドラフトのままにするよう依頼していなければ、gh pr ready でレビュー準備完了にしてください。PR がない場合は、gh pr create でドラフトではない PR を作成してください。--draft を使用するのは、ユーザーが明示的にドラフトを依頼した場合に限ります。既存のスタックに依存するレイヤーである場合、またはユーザーが別のベースを指定した場合を除き、デフォルトブランチをベースにしてください。

変更が必要な理由と変更内容を説明してください。該当する場合は、発端となったイシューを Fixes #<n> で参照してください。本文を編集する際は、既存の文脈を保持してください。依頼されない限り、ラベルやレビュアーを追加しないでください。

設定されたレビューを実施し、適切な範囲で検証する

完全なリリース依頼では、プロジェクトにサインオフのワークフローが定義されている場合、PR の作成または再利用と、意図したレビュー準備状態の設定を済ませた後に実行してください。リポジトリの現在のレビュー方針に従い、定義されていないゲートを独自に設けないでください。

リポジトリのチェックコマンドを確認してください。必須のローカルチェックと、変更した動作を対象とするテストを実行してください。ビルド前に必要なコードを生成してください。

• 変更が統合境界に及ぶ場合は、統合テストを含めてください。関連するテストが、気づかれないままスキップされずに実行されたことを確認してください。
• 既存の自動エンドツーエンドテストで、実行時のエビデンスを得られる場合があります。別個のリスクを確認する必要がない限り、そのテスト範囲を手動で重複して確認しないでください。
• カバーされていない統合上またはビジュアル上のリスクについては、手動で操作してください。影響を受ける代表的なフローを確認し、同じコンポーネントを使用するすべてのルートを確認する必要はありません。変更がレスポンシブレイアウトに影響する場合は、レスポンシブ表示も確認してください。
• CLI や API の動作は、焦点を絞ったテスト、または実際のコマンド／リクエストによって確認できる場合があります。リスクを検出できる方法を選択してください。
• 実行時の動作がない変更では、実行時のキャプチャは不要だったと明記してください。
• ローカル環境に不足がある場合は報告し、該当プラットフォームが必要なチェックは CI に任せてください。

チェックに合格した後で検証を繰り返したり範囲を広げたりするのは、新たな編集、失敗、または未解決のリスクがある場合に限ってください。検証プロセスを改善するために無関係なコードをリファクタリングしないでください。必要な修正はコミットしてプッシュしてください。

証拠を追加する

完全な出荷依頼では、正確なコマンド、結果、関連する未対応事項を含む Testing セクションを追加します。既存の自動化出力で十分な場合は、それを使用します。

簡潔なテキストの証拠は、言語タグ付きのコードフェンスに記載します。コマンドの記録には console、JSON には json、その他の出力には text を使用します。公開する前に、証拠から秘密情報や個人データを削除してください。

有用なスクリーンショットや録画は gh-image ではなく gh --attach で添付します。対応メディア、添付構文、検証については github-image-upload に従ってください。テキストの証拠で変更内容を示せる場合、メディアは不要です。証拠ファイルをコミットしないでください。

この完全なワークフローを呼び出すと、その証拠を PR に追加することが許可されます。証拠は PR 本文に記載し、既存の説明を維持し、必要な帰属表示のフッターがある場合は最後に残してください。

gh pr view で、意図した PR のベース、ヘッド、状態、証拠を確認します。

公開した PR を見守る

PR の公開と確認が完了したら、待機する前にマージコンフリクトを確認し、CI が完了するまで監視するために babysit を使用します。フィルタリングされたビューで失敗が隠れないよう、すべてのチェックを監視してください。監視のみの依頼では、コンフリクトを解消せずに報告します。

依頼の範囲内で失敗が発生した場合は、原因を調査し、修正して、影響を受けるチェックを実行し、コミットしてプッシュしたうえで、再度監視します。証拠が示す動作を変更した場合は、証拠を更新します。必須チェックを維持してください。チェックを回避したり、チェックが失敗、キャンセル、または想定どおりに実行されなかった場合に成功と報告したりしないでください。

依頼と無関係な失敗は、指示なく作業範囲を広げずに報告します。アクセスやインフラストラクチャが進行を妨げる場合は、阻害要因と未解決のチェックを明示します。

報告

PR へのリンクを記載し、実際の準備状況と CI の結果を示します。重要な変更点と検証上の未対応事項を要約します。該当するすべてのチェック結果で裏付けられている場合に限り、CI がグリーンだと述べてください。