Repository navigation
ci: dependabot targets main so the release sync refuses — main is 194 behind and 4 ahead #13654
Description
Activity
PR #13655 is blocked and now draft: the required check scans
git rev-list BASE..HEAD, so mergingmainpulls its three dependabot commits — all carryingCo-authored-by:— into scope. The merge commit exists precisely to put them in the ancestry, so the guard and the fix are in direct conflict. Three options written up on the PR; all need a decision. The five missing security upgrades (cryptography50.0.0,fast-uri3.1.5,hono4.13.0,undici8.10.0,nanoid3.3.17) must land onDev_new_guiunder any of them.Correcting the root cause in the description
I wrote that "dependabot opens its PRs against the repository's default branch, which is
main" and proposed pointing it atDev_new_gui. That misses an existing mechanism, and the real cause is narrower..github/workflows/dependabot-retarget.ymlhas existed since 2026-07-15 (#11696/#11724) and does exactly the proposed fix:on: pull_request_target: types: [opened, reopened, synchronize] concurrency: group: ${{ github.workflow }}-${{ github.event.pull_request.number }} cancel-in-progress: true jobs: retarget: if: >- github.event.pull_request.user.login == 'dependabot[bot]' && github.event.pull_request.base.ref == 'main'
It works — #13526 (
dependabot/uv/...) is onDev_new_guitoday because that workflow ran success five times on 2026-08-04. So dependabot PRs are being retargeted; the three that reachedmainare the exception, not the rule.What the run history shows
Runs for the branches behind the three divergent merges, on the day they merged:
14:47-15:02 success dependabot/uv/requirements-ci/uv-… (-> #13526, on Dev_new_gui) 14:18:55 skipped dependabot/npm_and_yarn/dot-mcp/… 14:18:55 cancelled dependabot/npm_and_yarn/dot-mcp/… 14:16:28 skipped dependabot/pip/pip-c7fce48c75skippedmeans theif:was false — i.e. the base was already notmainat that moment, so a retarget had previously succeeded. The workflow's own header documents what undoes it:@dependabot rebasereverts the base back to main (observed on #11566) … it runs onsynchronizetoo, so a Dependabot rebase/force-push that reverts the base is immediately re-retargeted.The likely defect
concurrency: cancel-in-progress: true.A rebase that reverts the base to
mainfiressynchronize; the re-retarget starts; a further event cancels it. Thecancelledrun above is that shape. The base then staysmain, and the PR merges there — silently, because nothing reports on it.So the fix is not "point dependabot at
Dev_new_gui" — that is already configured and working. It is to stop the corrective run being cancellable, e.g. dropcancel-in-progressfor this workflow (it is cheap and idempotent, so there is little reason to cancel it), or re-assert the base once more aftersynchronizesettles.Confidence: the timeline and the
cancelledrun fit, but I have not reproduced it — the three PRs are merged, so the event sequence cannot be replayed. Worth confirming against the next dependabot security PR rather than treating as proven.Unchanged
Everything about the merge itself still holds:
Dev_new_guiwas genuinely missing five security upgrades, and PR #13655 carries them. This only revises why the divergence happened and therefore which fix prevents a recurrence.Closed — verified delivered and present in
Dev_new_gui.Evidence
Artifact Value PR #13655 (merged) Verified against git show origin/Dev_new_gui:<path>on current base, not the PR diffAll
target-branchentries in.github/dependabot.ymlnow point atDev_new_gui(20 entries), and none targetmain— so the release sync is no longer refused.mainis 1 commit ahead, and that commit iscb526c5dd release: sync Dev_new_gui into main (47 commits) (#13972)— the sync merge itself, not the dependabot drift this issue reported.
This issue was fixed but left open because merges into
Dev_new_guido not auto-close —Closes #Nonly fires on the default branch. Closed as part of a sweep that cross-referenced merged PRs against open issues and verified each against current base. Every acceptance criterion was checked; partial delivery was left open rather than closed.
Summary
Sync Dev_new_gui → mainrefuses to run:mainis 194 commits behindDev_new_guiand simultaneously 4 commits ahead. The four are three dependabot merges from 2026-08-04 — #13515, #13523, #13524 — plus a merge commit.Root cause
Dependabot opens its PRs against the repository's default branch, which is
main. Every other PR in this project targetsDev_new_gui. So dependency updates land on a branch nobody develops on, and the working branch never receives them, whilemainaccumulates commits that make the release sync refuse to run.This also explains the standing "GitHub found 20 vulnerabilities on mrveiss/AutoBot-AI's default branch" banner printed on every push: it is measured against
main, which is 194 commits stale.The divergence is almost entirely nominal
Comparing every differing dependency between the two branches:
autobot-frontendandautobot-slm-frontendDev_new_guinewer on all 28,mainnewer on noneautobot-slm-backend/requirements.txtDev_new_guinewer (fastapi>=0.141.1vs0.140.1,uvicorn>=0.52.0vs0.51.0)requirements-ci/security.txtmainleads —cryptography==50.0.0vs49.0.0Examples of how far ahead
Dev_new_guialready is:apexcharts ^6.6.1vs^5.16.0,jsdom ^30.0.1vs^29.1.1,@testing-library/jest-dom ^7.0.0vs^6.9.1.So main's security bumps are superseded, with one exception.
Resolution taken
A merge of
mainintoDev_new_guikeepingDev_new_gui's side throughout and acceptingcryptography==50.0.0.Dev_new_guiadditionally carries aPyJWT[crypto]>=2.8.0line from #13411 thatmainlacks; that line is preserved.Conflicting files:
autobot-frontend/package.json,autobot-frontend/package-lock.json,requirements-ci/security.txt.Still open after this
The merge unblocks the sync once. Dependabot will target
mainagain on its next security update and the divergence returns. Options:Dev_new_gui—target-branch: Dev_new_guiin.github/dependabot.ymlfor the security/version ecosystems.Dev_new_gui, which also fixes the misleading vulnerability banner.mainon a schedule so the window stays small.Option 1 is the narrowest. Option 2 addresses the banner as well, but changes what an outside visitor sees first and affects every
Closes #Nin a PR body — this project already relies on issues being closed manually becauseClosesnever fires onDev_new_gui.