fix(ci): make dependabot auto-merge actually merge#11
Conversation
Three bugs were preventing the workflow from auto-merging clean
dependabot PRs:
1. The "Verify required CI workflows" step used `exit 0` to bail when
one of the required workflows had not run for the head SHA. But that
only ends the step — the subsequent approve/merge steps ran anyway
and failed at `gh pr review --approve`. Fix: emit a `proceed` step
output and guard the approve/merge steps with `if: steps.check.outputs.proceed == 'true'`.
2. The required-workflow list was static ("Go CI" AND "Docs CI"), so a
Go-only or actions-only PR (where Docs CI never runs thanks to path
filters) was always treated as "not ready" and skipped — but then
bug 1 made it try to merge anyway. Fix: treat a workflow that did
not run for the head SHA as N/A, and only block on workflows that
actually ran with a non-success conclusion. Still refuse to merge
if no relevant workflow ran successfully at all.
3. The body of the auto-approval was hardcoded to mention both
workflows even when only one was relevant. Minor: trimmed to
"Auto-approved after successful CI."
Note: this fix is necessary but not sufficient. The repo also needs
`Settings -> Actions -> General -> Allow GitHub Actions to create and
approve pull requests` enabled; without it the approve step still
fails with `GitHub Actions is not permitted to approve pull requests`.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: e678002ed9
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| conclusion="$(echo "${runs_json}" | jq -r --arg wf "${workflow_name}" \ | ||
| '[.workflow_runs[] | select(.name == $wf)] | (.[0].conclusion // "missing")')" | ||
|
|
||
| if [ "${conclusion}" != "success" ]; then | ||
| echo "Workflow '${workflow_name}' conclusion='${conclusion}'. Skipping." | ||
| exit 0 | ||
| fi | ||
| case "${conclusion}" in | ||
| missing|skipped) | ||
| echo "Workflow '${workflow_name}' did not run for ${HEAD_SHA} (likely path filter). Treating as N/A." |
There was a problem hiding this comment.
Treat in-progress workflow as blocker, not N/A
In .github/workflows/dependabot-auto-merge.yml, the verifier maps null conclusions to "missing" via (.[0].conclusion // "missing"), and then treats missing as non-blocking. For PRs that touch both code and docs, it is common for one workflow (e.g., Go CI) to finish first and trigger this job while the other (Docs CI) is still running with conclusion=null; this logic will incorrectly classify that running workflow as N/A and allow proceed=true, enabling auto-merge before all relevant CI has actually completed.
Useful? React with 👍 / 👎.
Summary
proceedoutput to the verify step andif:guards on the approve/merge steps, so we don't try to approve/merge after the verify step bailed out.Why
Recent runs were either silently failing at
gh pr review --approve("GitHub Actions is not permitted to approve pull requests") or skipping in a way that didn't actually stop the next step. Concretely, PR #8 (Go-only) and PR #4 (actions-only) couldn't be auto-merged because Docs CI never ran for them, and the static "both workflows required" check would have skipped — except the skip didn't gate the merge step.Repo setting still required
This fix is necessary but not sufficient. Repo currently has
```
"can_approve_pull_request_reviews": false
```
which blocks
gh pr review --approvefrom a GitHub-Actions token regardless of workflow logic. EnableSettings → Actions → General → "Allow GitHub Actions to create and approve pull requests"
before expecting auto-merge to actually work end-to-end.
Test plan