Skip to content

fix(ci): make dependabot auto-merge actually merge#11

Merged
mekedron merged 1 commit into
mainfrom
fix/dependabot-auto-merge
May 25, 2026
Merged

fix(ci): make dependabot auto-merge actually merge#11
mekedron merged 1 commit into
mainfrom
fix/dependabot-auto-merge

Conversation

@mekedron

Copy link
Copy Markdown
Owner

Summary

  • Adds a proceed output to the verify step and if: guards on the approve/merge steps, so we don't try to approve/merge after the verify step bailed out.
  • Treats a required workflow that didn't run for the head SHA (path filter) as N/A instead of as a blocker, while still refusing to merge when nothing relevant succeeded.
  • Trims the approval body to "Auto-approved after successful CI." since we no longer hardcode workflow names.

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 --approve from a GitHub-Actions token regardless of workflow logic. Enable
Settings → Actions → General → "Allow GitHub Actions to create and approve pull requests"
before expecting auto-merge to actually work end-to-end.

Test plan

  • Go CI is green on this PR
  • CodeQL is green
  • After merge, the next dependabot PR is auto-approved and auto-merged once CI is green (assuming the repo setting above is also enabled)

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`.
@mekedron mekedron merged commit 304f08b into main May 25, 2026
3 checks passed
@mekedron mekedron deleted the fix/dependabot-auto-merge branch May 25, 2026 21:39

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 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".

Comment on lines +40 to +45
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."

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge 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 👍 / 👎.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant