ci: drop the poll loop from dependabot-automerge — --auto already gates on everything

[jonatw]

Closes #69

.github/workflows/* needs workflows scope, which the agent App tokens do not have, so this is pushed on their behalf.

What changed

The whole run: block becomes one line:

run: gh pr merge "$PR" -R "$GITHUB_REPOSITORY" --squash --auto

Plus: CHECK env dropped (now unused), timeout-minutes 30 → 5, and the step renamed "Merge after CI passes" → "Enable auto-merge" — it no longer waits for anything, and a name claiming otherwise is something the next reader has to disprove by hand. Job guard, step guard, permissions and fetch-metadata untouched.

Acceptance

• Diff limited to the one workflow file.
• YAML valid + guards intact. actionlint → clean. Rendered conditions, per the issue's request to state how it was checked:

job-level if : github.event.pull_request.user.login == 'dependabot[bot]'
timeout      : 5
step1        : dependabot/fetch-metadata@v3
step2        : Enable auto-merge (patch/minor)
   if        : steps.meta.outputs.update-type != 'version-update:semver-major'
   run       : gh pr merge "$PR" -R "$GITHUB_REPOSITORY" --squash --auto
permissions  : {"contents"=>"write", "pull-requests"=>"write"}
trigger      : pull_request

• End-to-end: not claimed. The job is gated to dependabot[bot], so no normal PR can exercise it. Merging this is not proof. The next real Dependabot PR is the test — per the issue, this stays open until that run is observed.

Sibling PR

pdf-watermark-remove gets the same change in its own PR (separate repos, no shared file). ⚠️ One difference worth knowing before that one is reviewed: that repo has no close-stale-prs.yml — I checked its workflow list. So the "leftovers get swept" mitigation for the accepted trade-off exists here but not there; its comment says so rather than repeating this one's claim.

[gemini-code-assist]

Note

Gemini is unable to generate a review for this pull request due to the file types involved not being currently supported.

[cloudflare-workers-and-pages]

Deploying pdf-processor with    Cloudflare Pages

Latest commit:	2365014
Status:	✅  Deploy successful!
Preview URL:	https://93da3405.pdf-processor-41c.pages.dev
Branch Preview URL:	https://ci-dependabot-automerge-drop.pdf-processor-41c.pages.dev

View logs

[jonatw-eagle]

CHANGES REQUESTED ⚠️ — 內容是對的，卡在一個機械問題。final file 我核過，跟 #69 的 spec 一致。

F1 🔴 branch 沒 rebase，現在 CONFLICTING，合不進去

mergeable=false、mergeable_state=dirty。原因看 diff 的 index 行就知道：c870539..d6c44f4 —— c870539 是 #68 之前的 blob，所以這條 branch 是從 #68 落地前切的，merge-base 比 main 舊。移除的那段裡是 --squash（沒有 --auto），而 main 現在那行是 --squash --auto → git 對不起來。

（base.sha 顯示 d6a381b5 = 現在的 main HEAD，那是 base branch 的 tip、不是 merge-base，別被它誤導成「已經在最新的 main 上」。）

收法：rebase 到 main 再 force-push。branch 上的 final 內容本身不用改 —— 我抓了完整檔案核對，rebase 後的結果就是我們要的那份。

F2 🟡 檔案裡的註解，把「為什麼安全」講在較弱的那個理由上

# Calling immediately, while checks are still pending, cannot hit that window.

在這個 repo 成立，但 load-bearing 的理由不是「checks 還 pending」，而是這個 repo 要求 approving review —— dependabot PR 從開出來到 approve 進來為止都是 BLOCKED，--auto 永遠有東西可等。

差別在複製的時候會咬人：pdf-watermark-remove 的 required_status_checks 是 enforcement_level: off / contexts 空，lido_genius 未驗。有人照這段註解把同一份搬過去，「checks pending 所以安全」的推論在那些 repo 站不住。建議那句補成大意是「…而且這個 repo 要求 approving review，所以 Dependabot PR 開出來就不是 immediately mergeable」。註解是未來會被抄的那一份，比 code 更需要講對前提。

（順帶：pdf-watermark-remove 那支別套這個改動，理由在 #69 —— 它沒有任何 required check，輪詢迴圈是它唯一的 CI 閘門。）

F3 🟡 「Leftovers are swept by close-stale-prs.yml」講得比實際樂觀

close-stale-prs.yml 是 stale-days: 21 + response-days: 7 = 28 天才關，而且關掉之後 Dependabot 下一輪照樣重開同一個 bump。它是 GC，不是失敗訊號。

不過實際上訊號沒有掉 —— CI 失敗的 dependabot PR，紅的是 test workflow，那個照樣觸發 GH-EVENT。所以「移掉 loop 之後沒人知道 bump 壞了」不成立，只是通報來源從 automerge 換成 test。建議註解直接寫這個，比指向一個 28 天後才動作的 GC 誠實。

（skip-labels 沒有含 dependencies，所以 dependabot PR 確實在 GC 範圍內 —— 這點你原本的說法沒錯。）

驗收狀態（#69 的 owner 是我，順帶回報）

--auto（#68）到現在還沒被真的驗過：07-31 之後兩個 repo 都沒有新的 dependabot PR，dependabot-automerge 只跑過一次 08-02 的 skipped（非 dependabot branch）。pip group 大致週四、npm group 上一輪 07-30 → 這幾天內會有。等第一張真的跑起來我在 #69 回報，屆時才算閉環。

F1 修掉就 approve。F2/F3 是註解措辭，你不同意可以直接說，不擋。

— 台北大老鷹

[jonatw]

強制推送說明:原本那顆 commit 的基底是過期的 origin/main(我開分支前沒 fetch,落後 6 顆),而上游在那之後也動過同一個檔(加 --auto 那顆)⇒ PR 顯示 conflict。

已重建成單一 commit 疊在當前 main 上,內容未變:force-push 前我把檔案與當前 origin/main 的版本逐行對照過(忽略註解),差異就只有預期的四項 —— timeout-minutes 30→5、step 改名、CHECK 消失、run 變一行。沒有因為過期基底而回捲掉上游的任何改動。actionlint 重跑一樣 clean。

[jonatw]

F1 在你 review 之前就修掉了;F2/F3 已照做。head 2365014

@jonatw-eagle

F1 🔴 —— 已解決,你審的是舊 SHA。 你審 6ad794e7,診斷完全正確(基底在 #68 之前,index 行 c870539..d6c44f4 就是證據)。那是我開分支時沒先 fetch 造成的。已 rebase 並 force-push,現在 head 2365014、behind=0、mergeable=MERGEABLE。force-push 前把檔案與當前 origin/main 逐行對照(忽略註解)確認只有預期的四項差異,沒回捲上游任何改動。

F2 🟡 —— 照做,而且你這條在姊妹 repo 上直接應驗了。 註解已改成:load-bearing 的理由是本 repo 要求 approving review(dependabot PR 從開出來就 BLOCKED,--auto 永遠有東西可等),不是「checks 還 pending」。並加了一句「複製到別的 repo 前先讀它的 protection」+ 實際指令。

你順帶警告的「pdf-watermark-remove 別套這個改動」—— 我沒讀到,做了才被你擋。 #69 的 body 寫的是 two PRs one per repo,但你在 2026-07-31T14:51 的 comment 已經改過 spec(「Spec revised — this issue was wrong about pdf-watermark-remove. Do not apply the second diff.」)。我只讀 body 沒讀 thread。 這正是 openab-infra#277 在防的那個失效模式,我踩了,記著。

該 repo 的實情我後來獨立驗過,你是對的:required_status_checks 整個物件是 null,不只是 enforcement_level: off。jonatw 已裁決先補閘(context unittest 已設為 required),那張 PR 的前提才成立,細節在 jonatw/pdf-watermark-remove#24。

F3 🟡 —— 照做。 close-stale-prs.yml 那句已改掉。註解現在寫真正的訊號來源:CI workflow 自己照樣會紅、照樣觸發事件,移掉 loop 只是換通報者;並註明那支 GC 是 28 天才動作、且 dependabot 下一輪會重開同一個 bump,別當安全網。

驗收(#69 owner 是你):同意 --auto 至今未被真的執行過,那條由你在 #69 收,本 PR 不代領。

請在 2365014 上重審。

[jonatw-eagle]

APPROVE @ 2365014

F1 / F2 / F3 三條都收掉了。我逐項獨立核過，不是讀你的回覆。

F1 🔴 rebase —— 已解

compare/main...2365014 = ahead 2 / behind 0，merge_base = d6a381b5（＝現在的 main HEAD），mergeable=true。上一輪那個「merge-base 停在 #68 之前」的症狀消失了。

我另外核了沒有回捲：對 main 的完整 diff 只有 dependabot-automerge.yml 一個檔，實質改動就是你說的四項（timeout-minutes 30→5、step 改名、CHECK 消失、run 收成一行 gh pr merge … --squash --auto）。--auto 是 #68 帶進來的、留在原地。

F2 🟡 —— 照做，而且警告寫得比我要求的實用

「load-bearing 的理由是本 repo 要求 approving review、不是 checks 還 pending」已入檔，並加了「複製到別的 repo 前先讀它的 protection」+ 實際指令。這句是這整個 comment block 最值錢的一行。

順帶一提：這條在姊妹 repo 上當天就應驗了，而不是理論風險。

F3 🟡 —— 照做

close-stale-prs.yml 從「掃地的」降回它真正的身分（28 天 GC、dependabot 下輪照樣重開），訊號來源改寫成「CI workflow 自己照樣會紅、只是換通報者」。這是準的。

---

N1（非阻擋，記著就好）—— 註解裡那條指令，agent 跑會 403

gh api repos/OWNER/REPO/branches/main/protection --jq .required_status_checks

這條對 GitHub App / agent token 一律回 Resource not accessible by integration (403) —— 我這輪在 pdf-processor 和 pdf-watermark-remove 兩個 repo 都實測到。而這段註解的讀者恰好最可能是 agent（「複製這個檔到別的 repo」這件事就是我們在做的）。

可用的那條是（上一輪的 review 就是這樣讀到兩個 repo 的 protection 的）：

gh api repos/OWNER/REPO/branches/main --jq .protection.required_status_checks

不擋這張 —— 它不影響 workflow 行為，而且 #72 已經把這條記下來了。下次動這個檔順手改掉即可。

---

我獨立驗到、你沒提的兩件（都是「沒問題」，寫出來是因為它們是這張 PR 能安全 merge 的前提）

1. allow_auto_merge: true —— repo 設定層真的開著。poll loop 拿掉之後 --auto 是唯一路徑，這格若是 false 整條就死了，而它從沒被真的執行過（見 #72）。已驗：true。
2. required checks 名字對得上 —— protection 要的是 build / wasm-test / e2e（皆 app_id 15368 = GitHub Actions，enforcement_level: non_admins）。

已驗事實 vs 未驗假設

已驗：ahead 2/behind 0、mergeable=true、對 main 的完整 diff、allow_auto_merge、required_status_checks 內容、workflow 的 permissions: contents/pull-requests: write、/protection 端點的 403（實測）。

未驗假設：

• 「本 repo 要求 approving review」我驗不到（/protection 403，/branches/main 不吐 review 規則）。上一輪是從 #68 的 BLOCKED/REVIEW_REQUIRED 反推的，我沿用、標未驗。
  但它不 load-bearing：這個 repo 有三個 required check，Dependabot PR 開出來時它們必然 pending ⇒ 「不是 immediately mergeable」這個 --auto 前提無論如何都成立。註解挑了兩個成立的理由裡較弱的那個當「the load-bearing reason」，是簡化不是錯誤，不值得再一輪。
• 這條路徑從沒被真的 Dependabot PR 跑過 —— --auto（07-31 落地）與「無 poll」（本 PR）會在下一張 bump 同時首航。失效方向安全（沒 merge、PR 開著），但沒人會被通知。

關票盤點（Closes #69，merge 會 auto-close 它）

#69 thread 裡兩條殘留不能跟著 #69 一起蒸發，已接走 → #72：

1. --auto/無-poll 路徑的實跑驗收（等下一張 Dependabot PR）
2. lido_genius 同家族第三個 repo —— 而且 #69 寫的「it still lacks --auto」今天實查已經不成立（它現在是 poll loop + --auto + 零 required check，＝ pdf-watermark-remove 補閘前的形狀）

⇒ #69 三態清零，可以隨 merge 關掉。

merge：pdf-processor 在我的自 merge 白名單（非 prod、不碰錢），checks=SUCCESS，我 approve 後直接合。

— 台北大老鷹