Add dependabot PR diff-comparing workflow

[arx-ein]

Dependabot による Pull Request のレビュー (生成物の diff 比較) を自動で行う GitHub Actions workflow を追加します。

引き継ぎに伴い、@hyper1FU が検証と改善を行い、説明文を更新しました。
元の実装からの変更点と、確認したい点を以下にまとめています。

概要

Dependabot の PR に対して、master のビルド成果物と PR のビルド成果物を diff で比較する
GitHub Actions workflow を追加します。差分がなければ check passed、差分があれば check failed
となり、人間がレビューする、という運用を想定しています。

これまで各自が手元で「master と PR ブランチをそれぞれビルドして diff -r する」という手順を
実施していたものを、そのまま CI に載せた形です。

workflow は2本に分かれています。

review-dependabot-prs.yml — ビルドと比較（書き込み権限なし）

ジョブ	内容
build_base	マージ ref の第1親（＝マージ元の master）を checkout してビルド、dist-base として artifact 化
build_pr	マージ ref（＝マージ後の状態）を checkout してビルド、dist-pr として artifact 化
compare	両方を download して diff -r / diff -rq。差分があれば exit 1

3ジョブとも github.event.pull_request.user.login == 'dependabot[bot]' のガードが付いており、
通常の PR では全ジョブが skip されます。

report-dependabot-review.yml — PR への報告（書き込み権限あり）

Dependabot 起点の pull_request イベントでは GITHUB_TOKEN が read-only になり、
Secrets も渡されません。PR のコードを npm ci で実行する以上これは妥当な制限で、
したがってビルドする側の workflow から PR にコメントや approve はできません。

そこで比較結果を artifact に出し、workflow_run で発火する別 workflow が
pull-requests: write を持って報告を担当する構成にしました。この workflow は
master 側のファイルが使われ、PR のコードを一切実行しません。

なお pull_request_target は、書き込み権限を持ったまま PR のコードを実行することになるため
使用していません。

動作は環境変数で切り替えられます。

env:
  MODE: comment   # comment / approve / both

現在は comment（結果を PR にコメントするだけ）にしてあります。

動作検証について

この PR は本家では一度も実行されていません（この PR 自体が Dependabot 発ではないため
全ジョブが skip されます）。そのため fork (hyper1FU/utelecon.github.io) 上で
if の条件を自分のアカウント名に差し替えて検証しました。

基本動作

3ジョブとも最後まで通ります。所要時間は約6分（2つのビルドが並列で約5分、比較が25秒〜1分半）。

ビルドは決定的でした。中身を変えていない PR では diff が完全に空になります。
ビルド時刻やコミットハッシュが成果物に埋め込まれる、といった問題はありません。
この仕組みの大前提が満たされていることを確認できました。

actions/upload-artifact は v4 以降ドット始まりのファイルをデフォルトで除外するため、
include-hidden-files: true を追加しています。これがないと隠しファイルが比較対象から漏れます。

open な Dependabot PR 15件の実測

現在 open な Dependabot PR すべてについて、master に適用した場合の差分を測りました。
数字は差分のあったファイル数です。

@astrojs/rss      4.0.18 → 4.0.19       0
brace-expansion    5.0.5 → 5.0.9        0
devalue            5.6.4 → 5.8.1        0
fast-uri           3.1.0 → 3.1.7        0
fast-xml-builder   1.1.4 → 1.2.0        0
fast-xml-parser   5.5.11 → 5.7.1        0
immutable          5.1.5 → 5.1.9        0
js-yaml            4.1.1 → 4.3.1        0
nanoid            3.3.11 → 3.3.18       0
postcss            8.5.6 → 8.5.26       0
svgo               4.0.1 → 4.0.2        0
rollup            4.46.2 → 4.60.1     851
sharp / @astrojs/mdx / astro       ビルド失敗
vite / @astrojs/* / astro          ビルド失敗
esbuild / @astrojs/* / astro       ビルド失敗

ビルドが通る12件のうち11件が差分ゼロでした。

rollup で出た差分の内容

唯一差分が出た rollup について、849ファイル全件を機械的に検証しました。

CSS ルールの集合が一致           849 / 849 ファイル
うちルールの並び順が変わったもの  849 ファイル
CSS 以外の差が空白のみ           848 ファイル
CSS 以外に実体のある差            1 ファイル
<style> 要素数の変化 (4個 → 3個)  845 ファイル

rollup が変えたのは、インライン CSS を何個の <style> 要素に分けるかと、
ルールをどの順に並べるかだけでした。CSS のルールそのものは1バイトも変わっていません。

例外の1ファイルは good-practice/index.html で、差分は参照している JS のファイル名だけです
（client.D2WMwoKK.js → client.SBHmtuwi.js）。その JS 本体も差し替わっています。
Astro はファイル名に中身から計算したハッシュを含めるため、名前が変わった = 中身が変わった、
ということです。

CSS のルール順はカスケードに影響し得るため、機械的に無視してよい差分ではありません。
「差分あり → 人がレビュー」という設計自体は妥当だと考えます。

astro を含む3件について

astro を含む3件は、比較以前にビルドが通りません。

Package astro@7.0.7 not satisfy the version range "5.0.0 - 5.18.1"
  at checkPackageVersion (integrations/ignore-assets/index.ts:40)

integrations/ignore-assets/index.ts の TESTED_ASTRO_VERSION_RANGE の上限が
現行 master の astro バージョンちょうど（5.18.1）で、astro が上がれば必ず落ちる設計です。
astro 7 で ignore-assets / asset-colocation の動作確認をして定数を更新しない限り
マージできません。

この workflow の観点では3件とも check が失敗するので、見落とすことはありません。

サマリの出力方式について

rollup の diff は 19,218,645 バイト / 10,223 行になりました。minify 済みのため1行が
平均 1.9KB あり、当初の head -c 60000 では全体の 0.3% しか表示できません。

diff -rq によるファイル名一覧と件数をサマリに出し、全文は artifact に置いて
そちらを参照させる方式に変更しています。

Differences found in 849 file(s).

<details><summary>Changed files</summary>
（先頭100件のファイル名。それ以上は "... and N more."）
</details>

Download the `diff` artifact of this run for the full output.

承認の状態管理について

MODE を approve または both にした場合、承認したあとに PR の中身が変わるケース
（Dependabot が rebase する、より新しいバージョンで差し替わる等）に備えて、
Bot 自身の承認を取り消す処理を入れてあります。取り消すのは Bot の承認だけで、
人によるレビューには触れません。

通常はブランチ保護の「新しいコミットで既存のレビューを無効化する」設定で行うところですが、
このリポジトリにはブランチ保護がないため workflow 側で行っています。

以下の遷移は fork で確認済みです。

差分なし                  → 承認が付く / コメント "no differences"
差分なし → 差分あり        → 承認が取り消される / "N file(s) differ"
差分なし → ビルド失敗      → 承認が取り消される / "could not compare"
ビルド失敗 → 差分なし      → 承認が付き直す
差分なしのまま再実行       → 二重承認しない

コメントは毎回同じものを上書きするので、PR に積み上がりません。

なお MODE に approve を含める場合、リポジトリ設定の
「Allow GitHub Actions to create and approve pull requests」を有効にする必要があります
（デフォルトは無効で、そのままでは 422 で失敗します）。

netlify.yml とのビルド重複について

netlify.yml も PR ごとに npm run build を実行しているため、
Dependabot の PR 1件につき npm run build が3回走ることになります
（netlify / build_pr / build_base）。

netlify の成果物を再利用するには netlify.yml 側に upload-artifact を追加し、
この workflow を workflow_run で受ける構成が必要になりますが、全体が読みにくくなります。
重複は認識した上で、独立させたほうが単純で堅いと判断してこの構成にしています。

（build_base（master のビルド）については、他に実行している workflow がないため
純粋に新規の実行です。）

確認したい点

1. 比較対象をマージ後の状態に変更しました（事後報告）

元の実装は base.sha と head.sha を比較していました。head.sha は PR ブランチの先端で、
master にマージした状態ではありません。この PR の説明文および Slack での議論は
「マージした際のビルド成果物」と述べており、江利口さんのスクリプトも
git merge --no-commit --no-ff でマージ後の状態を作って比較しているため、
実装のほうを合わせました。

# PR 側: マージ後の状態
ref: refs/pull/${{ github.event.pull_request.number }}/merge

# base 側: 同じマージコミットの第1親
ref: refs/pull/${{ github.event.pull_request.number }}/merge
fetch-depth: 2
# → git checkout HEAD^1

base 側も変える必要がある点が要注意です。base.sha はイベント発生時点で固定される
一方、マージ ref は GitHub が別のタイミングで再計算します。両者がズレると、
PR と無関係な master の変更を差分として拾います。fork で再現したところ、
master に1ページ追加した状態で以下のようになりました。

merge^1 vs merge    →  0 件   （正しい）
base.sha vs merge   →  2 件   （PR と無関係な追加ページを誤検出）

merge^1 と merge は同じマージコミットの親子なので、定義上ズレません。
netlify.yml も refs/pull/N/merge を使っています。

なお、@dependabot rebase を先に打つ運用にすれば PR ブランチ自体が最新 master の上に
載るため、head.sha のままでもマージ後に近い状態を比較できます（孫さんの案）。
ただし手動コマンドを挟むことになるため、CI 側で完結する形を採りました。
この判断でよいかご確認ください。

2. 自動承認の条件をどうするか

現状 master にブランチ保護が掛かっておらず、承認ゼロのままマージされている PR が
大半です。つまり approve はマージの条件になっていないため、Bot が approve しても
人の作業は減りません。

その意味では、コメントで結果を伝えるだけでも目的は足りている可能性があります。
approve に意味が出るのは、ブランチ保護でレビューを必須にした上で auto-merge を使い、
人手を介さずマージまで完了させる場合です。

MODE の値をどうするか、ご意見をいただきたいです。

別件として提案したいこと

.node-version の導入

リポジトリに .node-version / .nvmrc / package.json の engines はいずれも存在せず、
node-version: 24 が netlify.yml / astro.yml / この workflow に直書きされています。

Slack で「Node v24 であることを確認（はじめはしていなくて躓いた）」という話が出ていた通り、
一元管理がないことによる実害が既に出ています。.node-version を導入して
node-version-file に統一することを別 issue として提案したいですが、
この PR では既存に合わせて直書きのままにしています（この PR だけ変えると浮くため）。

web_development ラベルの自動付与

.github/dependabot.yml を追加すれば実現できます。これは #2030 とは独立しているので、
別 PR として出すのがよいと考えています。

astro のバージョンゲート

TESTED_ASTRO_VERSION_RANGE に引っかかる3件は、astro 7 での動作確認が必要です。
別 issue として切るのがよさそうです。

[github-actions]

🚀 Deployed on https://deploy-preview-2030--utelecon.netlify.app