継続的インテグレーションのセットアップ
プッシュ時と全ての変更依頼時に何を実行するかを決定し、それをプロジェクトのフォージが理解できる構文で記述します。このファイルにおける決定はフォージに依存しません。エコシステムを検出し、何を実行する必要があるかを決定し、マトリックスを選び、キャッシュを決定します。それらの決定を表現する構文はフォージに依存するため、GitHub Actions用の references/github-actions.md とGitLab CI/CD用の references/gitlab.md に分かれています。設定を記述する前に、該当する参照ファイルを読んでください。一方のフォージの構文を他方のキーワードを翻訳して記述しないでください。なぜなら、トリガー、マトリックス、キャッシュの形状が異なるからです。
スコープ
このスキルは、どのチェックを実行するか（どのチェックが実行されるか、どのトリガーで、どのバージョンで、どのキャッシュを使用するか）を担当します。このスキルが作成するワークフローおよびパイプラインファイルは他の2つのスキルと共有され、それらの間の境界はファイルの記述ではなくルール領域に基づいています。
後述のCIルール（R-CI-*）はここに属します。SECルール（同じファイルのセキュリティ態勢、例えばピン留めされたアクションSHA、最小権限、依存関係更新プログラム、ブランチ保護、ピン留めされたイメージなど）は oss-harden に属します。RELルール（信頼できるパブリッシング、証明書、承認ゲートを伴うレジストリへのビルド成果物の公開）は oss-publish に属します。このスキルで作業する際は、permissions: ブロックを追加したり、SHAをピン留めしたり、ブランチ保護を設定したり、パブリッシュジョブを記述したりしないでください。プロジェクトにそれが必要であることに注意し、その作業を担当するスキルに引き継いでください。
ビルドされた静的サイトをフォージ自身のPagesホスティングにデプロイすることもプッシュ時に実行されるため、レジストリリリースを担当する oss-publish ではなく、ここに残ります。どのルールもそれを必須とはしていません。プロジェクトがサイトを公開するのはそれが存在するからであり、そのため、リポジトリがサイトをビルドし、ユーザーがデプロイを要求した場合にのみ記述されます。
原則
ステップ、シークレット、設定値を追加する前にすべてを検証してください。リポジトリの実際の状態を確認し、推測で判断しないでください。不確かな場合は、もっともらしい答えをでっち上げるのではなく、質問してください。
パイプライン内でシェルロジックを記述する代わりに、プロジェクト自身の自動化を呼び出してください。jest --coverage --ci ではなく npm test を実行するステップは、パイプラインとコントリビューターのローカルマシンで同じコマンドを実行することを意味し、これはR-CI-02がチェックすることです。そのような自動化が存在しない場合は、プロジェクトに追加するか、インラインコマンドにフォールバックするかを質問してください。
リポジトリにすでにテスト、Dockerfile、パイプラインが含まれている場合でも、ポリシーの選択肢を提示し、推測しないでください。変更依頼で何を実行するか、リリースビルドのトリガーは何か、デプロイをどのように行うかはユーザーが決定することです。コードは何が可能かを示すだけで、何が望まれているかを示すものではありません。
プロセス
ステップ1: フォージを検出する
既存の .github/workflows/ ディレクトリまたは .gitlab-ci.yml ファイルを探し、gitリモートで github.com または gitlab ホストを確認するか、どちらのシグナルもない場合は直接質問してください。これにより、ステップ6と7でどの参照ファイルが適用されるかが決まります。ユーザーがフォージを明示的に指定した場合は、リポジトリで見つかったどのシグナルよりもそれを優先してください。
ステップ2: リポジトリを分析する
ソースファイルとパッケージマニフェストから言語とランタイムを特定し、プロジェクトがサポートすると主張するバージョン範囲を記録します。ステップ4のマトリックスは、R-CI-03に従い、最も古いものから最も新しいものまで、サポートされているすべてのバージョンをカバーする必要があります。
プロジェクトがすでに定義している、適用可能なすべてのlint、テスト、タイプチェック、ビルドコマンドを見つけてください。これにはパッケージマネージャーのスクリプト、Makefile、Rakefile、toxやjustのようなツールが含まれ、その引数と副作用を十分に理解できるように詳しく読んでください。存在しないチェックのカテゴリをでっち上げないでください。ドキュメントリポジトリにはビルドがなく、小さなスクリプトにはリンターがないこともあります。リポジトリにCONTRIBUTINGガイドがある場合、そのコマンドとプロジェクトの自動化は一致していなければなりません。矛盾がある場合は、どちらかをCIにコピーする前に解決してください。
既存のCI設定を変更する前に必ず読み、拡張すべきか置き換えるべきかを判断してください。
プロジェクトがコミットしているすべてのロックファイル（package-lock.json、Gemfile.lock、poetry.lock、Cargo.lock など）と、各インストールコマンドが安全に再利用できるパッケージマネージャーのダウンロードキャッシュを特定してください。インストールされた依存関係ディレクトリがキャッシュであると想定しないでください。
.env.example を見つけ、ソース内で必要な環境変数を検索してください。これにより、実行に失敗した後ではなく、生成前にシークレットが必要なステップを特定できます。
ステップ3: 調査結果を提示し、質問する
ステップ2で見つけた内容を要約し、コードだけでは答えられない選択肢について質問してください。プルリクエストやマージリクエストで何を実行するか、リリースビルドのトリガーは何か、既存のCIを拡張するか置き換えるか。このプロジェクトに適用されるものだけを質問してください。Dockerfileがないプロジェクトにレジストリについて質問しないでください。
ステップ2で静的サイトを生成するビルドが見つかった場合は、デプロイも行うべきか、どこにデプロイするかを質問してください。サイトはチェックとしてビルドされ、公開されないこともあります。そのため、静的ビルドはデプロイの同意ではなく、質問として扱ってください。
ステップ4: マトリックスを選択する
ステップ2で特定したサポート対象のリリースラインからバージョンマトリックスを構築します。単一の固定バージョンからではなく、プロジェクトがサポートすると主張するすべてのメジャーまたはマイナーリリースラインを含めてください。サポート範囲が明示されていないプロジェクトには、でっち上げたマトリックスではなく単一バージョンのパイプラインを使用します。マニフェストが主張していないサポート範囲をでっち上げないでください。範囲が連続しており、プロジェクトがサポートする意図のないリリースラインが含まれている場合は、宣言された範囲を修正してください。黙ってサブセットをテストしないでください。
ステップ5: キャッシュを決定する
パッケージマネージャーのダウンロードデータ、またはツールの公式ドキュメントが安全に再利用できるとしているその他のディレクトリのみをキャッシュします。検出されたパッケージマネージャーをサポートし、ロックファイルをハッシュするフォージの公式ランタイムセットアップアクションを優先します。それ以外の場合は、ロックファイルと、その内容を変更するすべての互換性境界（オペレーティングシステム、アーキテクチャ、ランタイム、パッケージマネージャーなど）に基づいて明示的なキャッシュをキー設定します。フォールバックキーはオプションであり、これらの境界のいずれかを越えてはなりません。ロックファイルがない、または再利用可能なダウンロードキャッシュがないプロジェクトは、キャッシュステップなしで進めます。
ステップ6: 設定を記述する
ステップ1で選択したフォージの参照ファイルを開き、その構文に正確に従ってください。両方の参照ファイルは、デフォルトブランチへのプッシュとすべての変更依頼時のトリガー（R-CI-01）、すべてのジョブのタイムアウトと同一ブランチ上の後続実行のキャンセル（R-CI-05）、およびステップ5のキャッシュ決定（R-CI-04）をカバーしています。両方ともPagesデプロイメントセクションを含みますが、これはステップ3でプロジェクトがそれを望むと確認された場合にのみ使用します。どちらの参照ファイルも権限、SHAピン留め、パブリッシュについてはカバーしていません。これらはここで記述するファイルには含めないでください。
ステップ7: 提示前に検証する
フォージのバリデーターが利用可能な場合はそれを使用して設定が構文的に有効であることを確認し、呼び出されるすべてのコマンドが存在し、ローカルで同じ順序で成功することを確認してください。GitLabの場合は、CI Lintを使用してインクルードされた設定を展開して確認します。GitHubの場合は、Actionsエディタでワークフローを検査するか、ユーザーが外部変更を承認した場合はブランチにプッシュして確認します。汎用のYAMLパーサーはGitHubの式やワークフローセマンティクスを検証できません。パイプラインが必要とするシークレットを、それぞれを追加するコマンドとともにリストアップしますが、そのコマンドは実行しません。マトリックスがすべてのサポート対象リリースラインと一致し、すべてのジョブにタイムアウトがあり、安全な場合に後続実行のキャンセルに参加していることを確認します。
ステップ8: 結果を提示する
生成されたファイル、検出および決定された内容の短い要約、設定すべきシークレットのリスト、およびリポジトリまたはプロジェクトレベルでユーザーが設定する必要がある残りの項目（ブランチ保護や環境承認者など）を提示し、それをここで試みるのではなく、それを担当するスキルを指名してください。
このスキルが所有するルール
R-CI-01: CIはデフォルトブランチへのすべてのプッシュとすべての変更依頼で実行される
R-CI-02: CIはコントリビューティングガイドが人間に与えるものと同じlint、テスト、ビルドコマンドを実行する
R-CI-03: テストマトリックスは、プロジェクトがサポートすると主張するすべてのランタイムバージョンをカバーする
R-CI-04: 依存関係キャッシュはロックファイルに基づいてキー設定される
R-CI-05: すべてのジョブにはタイムアウトがあり、同一ブランチの後続実行はキャンセルされる