ci(deps): point Dependabot version updates at staging - #78
Merged
Conversation
`main` only moves at release time, by squash-merging `staging`. A bump that lands on `main` alone is reverted by the next release, because the squash applies staging's tree against a merge base that predates it — which is how ten dependabot PRs accumulated against a branch that could not keep them. Also adds the npm ecosystem, which had no entry at all: every npm PR in the queue arrived as a security update rather than a version update, so ordinary dependency drift was only ever caught by an advisory. Astro, Starlight and their plugins are grouped, since they resolve together. Security updates still target the default branch — `target-branch` does not apply to them — so advisory PRs will keep appearing against `main`.
There was a problem hiding this comment.
Pull request overview
Updates the repository’s Dependabot configuration so routine dependency version bumps land on staging (the branch that actually flows into main at release time), preventing version-update PRs from being effectively reverted by the next staging → main squash release process.
Changes:
- Retarget Dependabot GitHub Actions version updates to
staging. - Add a new npm Dependabot entry targeting
staging, with grouping to keep Astro/Starlight-related upgrades together and everything else in a catch-all group. - Document the
target-branchcaveat that security updates will still target the default branch (main) due to GitHub constraints.
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
33 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes the root cause behind #68 §7 — ten dependabot PRs piled up against
main, a branch that cannot keep them.The problem
mainonly moves at release time, by squash-mergingstaging. A bump merged intomainalone is reverted by the next release: the squash applies staging's tree against a merge base that predates the bump, so the older versions win. Anything meant to survive a release has to arrive throughstaging.What changes
target-branch: stagingon the existinggithub-actionsentry.npmentry, which did not exist. That is why every npm PR in the queue (Build(deps): Bump @astrojs/rss from 4.0.18 to 4.0.19 #33, Build(deps): Bump svgo from 4.0.1 to 4.0.2 #35, Build(deps): Bump sharp, @astrojs/starlight, astro, starlight-blog and starlight-llms-txt #37, Build(deps): Bump postcss from 8.5.15 to 8.5.25 #57, Build(deps): Bump fast-uri from 3.1.2 to 3.1.5 #64, Build(deps): Bump mermaid from 11.15.0 to 11.16.1 #65, Build(deps): Bump dompurify from 3.4.7 to 3.4.13 #66, Build(deps): Bump js-yaml from 4.2.0 to 4.3.1 #69, Build(deps): Bump nanoid from 3.3.12 to 3.3.18 #70) arrived as a security update: with no npm configuration, Dependabot never ran version updates, so ordinary dependency drift was only ever surfaced by an advisory. Astro, Starlight and their plugins are grouped together because a lone bump among them usually fails to resolve; everything else lands in one catch-all PR.Caveat, documented in the file
target-branchgoverns version updates only. Dependabot security updates are always raised against the default branch and ignore it, so advisory-driven PRs will keep appearing againstmainand still need folding intostagingby hand. That is a GitHub constraint, not a configuration choice.Follow-up
The ten open npm PRs are superseded by #73 and should be closed rather than merged; #32 is closed by #77, which landed the same
setup-nodebump onstaging.Part of #68.