ci: 自動更新 PR が無検証で提案されるのを止める

[hal-shu-sato]

このPRは #997 に積んでいます(base が fix/run-schema-validation)。#997 の lint:jsonschema の修正が前提です。#997 が先にマージされると base は自動的に source へ付け替わります。

問題

check-update.yml が作る PR は GITHUB_TOKEN で作成されるため、GitHub の再帰防止によってワークフローを一切トリガしません。lint.yml も CodeQL も走らないので、#968 は 2025-10-18 に開かれて以来、毎日更新され続けているのにチェックが 0 件です。

このリポジトリでいちばん頻繁にデータが入る経路が、唯一まったく検証されていない経路でもある、という状態でした。

やったこと

PR を作る前に生成と検証を回し、結果を PR 本文に書き込みます。

      - name: Generate the published JSON
        id: generate
        continue-on-error: true
        run: yarn run release
      - name: Validate the generated data against the schema
        id: schema
        continue-on-error: true
        run: yarn run lint:jsonschema

PR 本文にはこう入ります。

Update some packages data

Schema validation: passed

失敗した場合は **FAILED** — check the workflow run before merging になります。

設計上の判断

ゲートにしていません

前回の PR で選択肢として挙げた「check-update 内検証」には「1 件でも不正だと更新 PR ごと止まる」という欠点がありました。これを避けています。

• 両ステップとも continue-on-error: true — 検証が落ちても PR は作られます
• 結果は PR 本文に残るので、レビュー時に見えます
• PR が作られた後で job を失敗させるので、スケジュール実行は赤くなります

不正なデータが 1 件混ざったせいで、同じバッチの正常な更新まで差し止められるより、見える形で提案されるほうが良いという判断です。公開の手前には #997 で入れた release.yml のゲートがあるので、最終防波堤はそちらが担います。

bash を使わず 2 ステップに分けています

この job は windows-latest で動きます。複数行の run: は既定で PowerShell になり、GitHub が付ける終了コードのチェックは最後のコマンドしか見ません。1 ステップにまとめると、生成が失敗しても検証が成功すればステップ全体が通ってしまいます。

shell: bash に切り替える手もありますが、Windows ランナーに Git Bash 依存を持ち込むより、既存の yarn ステップと同じ既定シェルのまま分けるほうが安全と判断しました。

完全な解決には PAT が要ります(要メンテナ操作)

この検証はスキーマ検証だけで、prettier / eslint / CodeQL は依然走りません。それらまで走らせるには PR の作成者を変える必要があります。

そのための入口を 1 行だけ用意しました。

token: ${{ secrets.CREATE_PR_TOKEN || secrets.GITHUB_TOKEN }}

CREATE_PR_TOKEN という名前で PAT をシークレット登録するだけで、自動更新 PR が通常どおり全ワークフローをトリガするようになります。シークレットが無い間は今と同じ挙動のままです(存在しないシークレットは空文字列に評価され、フォールバックが効きます)。

PAT の発行と登録は資格情報の取り扱いなので、こちらでは行いません。

確認したこと

• prettier --check が緑
• YAML としてパース可能なことを確認

このPRは中間ブランチ宛てなので、現時点では CI が走りません(まさに #996 が直そうとしている問題です)。#996 がマージされれば stacked PR にも CI が回るようになります。