Repository navigation
ci(dependabot): weekly grouped updates and shared auto-merge for minor and patch - #141
singlerider wants to merge 5 commits into
Conversation
Individual dependabot PRs pile up faster than one engineer can review them and go stale until they conflict (bbot-enterprise#141). Every ecosystem now runs weekly against dev and opens at most two grouped PRs: one for minor and patch bumps, one for majors. A pull_request_target workflow enables auto-merge (squash) on the minor/patch group so it lands once required checks pass. Majors still need a human.
The auto-merge job was a byte-identical copy in ten repositories. It now calls dependabot-auto-merge.yml in blacklanternsecurity/.github, pinned by SHA, so the fetch-metadata pin and merge policy live in one place. The trigger moves from pull_request_target to pull_request. Dependabot branches live in this repository, so the privileged target context was never needed and zizmor flags it as a dangerous trigger.
blacklanternsecurity/.github is private, so public repositories cannot call reusable workflows from it and the run failed as a workflow file issue. The shared workflow lives in blacklanternsecurity/CLA, which is public and already hosts cla-reusable.yml.
dev carries no required checks (#139), so gh pr merge --auto would merge immediately rather than on green. The shared workflow now waits for every other check on the head commit, refuses on failure or cancel, and merges with --match-head-commit. The caller grants checks: read so it can read check state.
Aligns with the SHA the other shared CLA workflows are pinned to. The auto-merge workflow is unchanged between the two commits.
en0f
left a comment
There was a problem hiding this comment.
Auto-merge can't get past the review rule on dev. dev has an active ruleset ("protecc") that requires a pull request and passing status checks. This PR, which targets dev, shows "At least 1 approving review is required by reviewers with write access." The shared workflow pinned at e532142 waits for checks, then runs gh pr merge --squash straight away. Nothing approves the PR first, so that merge call will be rejected every time.
The workflow and the PR description both assume "dev carries no required checks (#139)". The ruleset says otherwise: on this PR, Python Tests and Rust Tests are marked Required.
Fix: either have the shared workflow approve the PR (gh pr review --approve) before merging, with "Allow GitHub Actions to create and approve pull requests" turned on, or add a bypass for this path in the ruleset. I couldn't see the ruleset's bypass list. If GitHub Actions is already on it, this isn't a problem.
Part of blacklanternsecurity/bbot-enterprise#141.
Change
.github/dependabot.yml:cargo,uv,github-actionseach run weekly againstdev, grouped into one minor/patch PR and one major PR per ecosystem..github/workflows/dependabot-auto-merge.ymlis a caller stub for the sharedblacklanternsecurity/CLA/.github/workflows/dependabot-auto-merge.yml(public repo, so public callers can reach it), pinned by SHA. On non-major Dependabot PRs the shared workflow waits for every other check on the head commit, refuses on fail or cancel, then runsgh pr merge --squash --match-head-commit. The caller grantschecks: read. No per-repo copy of the logic.Trigger is
pull_request, notpull_request_target. Dependabot branches are same-repo, so the privileged context is unnecessary.Depends on
feat/dependabot-auto-mergemerging tomain(via feat(ci): host shared test, release, and publish workflows CLA#3). The pinned SHA is already on that branch, and stays valid after a merge commit.devcarries no required checks (bbot-enterprise#139), so the green gate is in the workflow and "Allow auto-merge" is not needed.Validation
CI
This PR only touches dependabot config. rust-tests/cli-tests/python-tests fail on upstream/dev c15f523 too (clippy: deprecated
fetch_updatein src/health.rs:455). Fixed in #139.