差分があるサービスだけbuildする — 汎用パターンで理解する

01課題の正体 — diffを実行対象へ変換する

Dockerfile探索もpaths-filterも、入口と出口は同じです。

教材は、Dockerfileのあるディレクトリを候補として集め、git diff の変更ファイルと照合し、build-targets を後続matrixへ渡します。覚えるべきなのはシェルの細部より、このデータ変換です。

022つの実装法 — 手製shellとpaths-filter

学習には手製方式、現場の汎用テンプレートには宣言的フィルタが扱いやすい。

03なぜMakefile確認をbuild側に残すのか

detectは影響判定、buildは実行能力の確認。段階的に絞ると責務が崩れません。

質問660の回答では、find-build-targets でMakefileと aws.mk のincludeまで確認すると複雑になり、読みづらくなる点が理由として挙げられています。build側ならAWSは aws.mk、GCPは gcp.mk という固有条件を自然に持てます。

04汎用化の核心 — 依存マップを宣言する

サービス配下だけでなく、共有コードとbuild定義の波及先を決めます。

- uses: dorny/paths-filter@v4
  id: changes
  with:
    filters: |
      slack-metrics:
        - 'services/slack-metrics/**'
        - 'aws.mk'
        - 'go.mod'
        - 'go.sum'
      db-migrator:
        - 'ops/db-migrator/**'
        - 'aws.mk'
        - 'go.mod'
        - 'go.sum'

同じ共有パスを複数フィルタへ含めれば、その変更時に changes 出力が両サービス名を返します。サービス名はbuildだけでなく、migrate・deploy・task definition登録の共通キーにもできます。

05壊れにくいjob契約 — JSON、空配列、status

動くhappy pathだけでなく、何も変わらない時を正しく表現します。

jobs:
  detect:
    outputs:
      targets: ${{ steps.changes.outputs.changes }}

  build:
    needs: detect
    if: needs.detect.outputs.targets != '[]'
    strategy:
      matrix:
        service: ${{ fromJSON(needs.detect.outputs.targets) }}

06AIに頼むときの最小プロンプト

コード生成より先に、依存関係と受け入れ条件を渡します。