Group Dependabot security updates and keep v3-3-test covered - #70556

potiuk · 2026-07-27T18:27:55Z

Dependabot groups only apply to security updates when they declare
applies-to: security-updates — without it, a group covers version updates
only. Every group in our config relied on that default, so alert-driven bumps
bypassed grouping entirely and opened one PR each:

Bump axios from 1.17.0 to 1.18.0 in /providers/edge3/src/airflow/providers/edge3/plugins/www #70145 axios (edge3 www), Bump mermaid from 11.14.0 to 11.15.0 in /airflow-core/src/airflow/ui #69132 / Bump mermaid from 11.15.0 to 11.16.0 in /airflow-core/src/airflow/ui #69137 mermaid (core UI)
Bump gitpython from 3.1.52 to 3.1.54 in /airflow-core #70428 gitpython, Bump zeep from 4.3.2 to 4.3.3 #68780 zeep (pip)
Bump @hey-api/openapi-ts from 0.98.2 to 0.99.0 in /airflow-core/src/airflow/api_fastapi/auth/managers/simple/ui #69265 @hey-api/openapi-ts (auth UI)
Bump google.golang.org/grpc from 1.79.3 to 1.82.1 in /go-sdk #70226 google.golang.org/grpc, Bump golang.org/x/net from 0.48.0 to 0.55.0 in /go-sdk #69214 golang.org/x/net (/go-sdk)

Each one has a matching Dependabot alert — they are security updates, not
version updates.

This adds a security-updates group to every entry that targets the default
branch, so those bumps get batched the way version updates already are.

Three things worth calling out for reviewers:

The v3-3-test entries are deliberately untouched. Dependabot raises
security updates against the default branch only, and per the docs an entry
using target-branch is version-updates only. A security group there would
never match anything, so I added comments saying so rather than leaving it
looking like an oversight.
*-major-version-updates groups are widened and renamed. The core-ui,
auth-ui and registry entries already had applies-to: security-updates
groups, but restricted to update-types: [major] — so minor and patch
security updates fell through ungrouped. They now cover all security updates
and are renamed *-security-updates to match what they do. This changes the
Dependabot branch names for those groups; no open PRs currently use them.
New gomod entry for /go-sdk. That directory had no configuration at
all. Dependabot still raises security PRs for it (hence the two Go bumps
above) but cannot group them without an entry. This adds weekly grouped
version updates plus a security group.
No new backport automation. Auto-labelling security PRs backport-to-v3-3-test
and letting automatic-backport.yml cherry-pick them was the other option, but
lock file picks across diverged branches fail often enough that it would mostly
generate failed-backport noise. Mirroring the config is the reliable route.

Major version updates in the UI directories (i18next 25→26,
eslint-plugin-unicorn, @visx/shape, @stylistic) stay ungrouped — the
minor+patch groups exclude them on purpose and I did not change that.

Keeping v3-3-test covered

Security updates only ever target the default branch, so a fixed version landing
on main does not reach the maintenance branch by itself. Cherry-picking one over
is unreliable — these commits carry lock file diffs, and main's lock files have
long diverged from v3-3-test's, so the pick conflicts more often than not.

Letting Dependabot maintain the branch directly sidesteps that: it resolves the
dependency and regenerates the lock file on v3-3-test itself. Six directories
were tracked on main but not on the maintenance branch, so a fixed version had
no route there at all:

npm: edge3 www, fab www, /registry, react plugin template
uv: /dev/breeze
gomod: /go-sdk

They now have target-branch: v3-3-test entries following the policy the branch
already applies to core-ui and auth-ui — minor and patch only, majors ignored.
Every ecosystem/directory tracked on main is now also tracked on v3-3-test
(10 entries each). A fix that needs a major bump still has to be backported by hand.

dev/update_github_branch_config.py generates the same six entries, so cutting
the next release branch does not silently reintroduce the gap. I verified this by
running it for a hypothetical v3-4-test: 10 main / 10 v3-4-test / 10 v3-3-test,
nothing unmirrored.

One thing worth knowing for reviewers: that script patches dependabot.yml by
exact string match, and one of its anchors requires interval: "weekly" to be
immediately followed by target-branch: v3-3-test. Explanatory comments therefore
live at the top of the file rather than inline, so the anchors stay intact.

Was generative AI tooling used to co-author this PR?

Yes (please specify the tool below)

Generated-by: Claude Code (Claude Opus 5) following the guidelines

🤖 Generated with Claude Code

Dependabot groups only apply to security updates when they declare `applies-to: security-updates`; without it a group covers version updates only. Every group in our config relied on that default, so alert-driven bumps bypassed grouping entirely and opened one PR each - axios in edge3 (apache#70145), mermaid (apache#69132, apache#69137), gitpython (apache#70428), zeep (apache#68780), @hey-api/openapi-ts (apache#69265) and the two /go-sdk Go bumps (apache#70226, apache#69214). Add a `security-updates` group to every entry that targets the default branch. Entries carrying `target-branch: v3-3-test` are deliberately left alone: Dependabot raises security updates against the default branch only, so a security group there would never match. Comments note this so it does not look like an oversight. The three existing `*-major-version-updates` groups were already `applies-to: security-updates` but restricted to `update-types: [major]`, so minor and patch security fixes fell through ungrouped. They are widened to cover all security updates and renamed to `*-security-updates` to match what they actually do. Also adds a `gomod` entry for /go-sdk, which had no configuration at all - its Go security bumps were arriving individually because Dependabot raises security updates for ecosystems with no entry, but can only group them when one exists. Generated-by: Claude Opus 5 (1M context)

Dependabot raises security updates against the default branch only, so a fix that lands on main does not reach a maintenance branch by itself. Cherry-picking one over is unreliable: these commits carry lock file diffs, and main's lock files have long diverged from v3-3-test's, so the pick conflicts more often than not. Letting Dependabot maintain the branch directly avoids that entirely - it resolves the dependency and regenerates the lock file on v3-3-test itself. Six directories were tracked on main but not on the maintenance branch, so a fixed version had no way of reaching it: - npm: edge3 www, fab www, /registry, react plugin template - uv: /dev/breeze - gomod: /go-sdk They now have `target-branch: v3-3-test` entries following the policy the branch already uses for core-ui and auth-ui: minor and patch only, majors ignored. A fix that needs a major bump still has to be backported by hand. `dev/update_github_branch_config.py` generates the same six entries, so cutting the next release branch does not silently reintroduce the gap. Generated-by: Claude Opus 5 (1M context)

github-actions · 2026-07-28T12:03:31Z

Backport successfully created: v3-3-test

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
✅	v3-3-test

…red (#70556) * Group Dependabot security updates Dependabot groups only apply to security updates when they declare `applies-to: security-updates`; without it a group covers version updates only. Every group in our config relied on that default, so alert-driven bumps bypassed grouping entirely and opened one PR each - axios in edge3 (#70145), mermaid (#69132, #69137), gitpython (#70428), zeep (#68780), @hey-api/openapi-ts (#69265) and the two /go-sdk Go bumps (#70226, #69214). Add a `security-updates` group to every entry that targets the default branch. Entries carrying `target-branch: v3-3-test` are deliberately left alone: Dependabot raises security updates against the default branch only, so a security group there would never match. Comments note this so it does not look like an oversight. The three existing `*-major-version-updates` groups were already `applies-to: security-updates` but restricted to `update-types: [major]`, so minor and patch security fixes fell through ungrouped. They are widened to cover all security updates and renamed to `*-security-updates` to match what they actually do. Also adds a `gomod` entry for /go-sdk, which had no configuration at all - its Go security bumps were arriving individually because Dependabot raises security updates for ecosystems with no entry, but can only group them when one exists. Generated-by: Claude Opus 5 (1M context) * Mirror remaining dependency directories onto v3-3-test Dependabot raises security updates against the default branch only, so a fix that lands on main does not reach a maintenance branch by itself. Cherry-picking one over is unreliable: these commits carry lock file diffs, and main's lock files have long diverged from v3-3-test's, so the pick conflicts more often than not. Letting Dependabot maintain the branch directly avoids that entirely - it resolves the dependency and regenerates the lock file on v3-3-test itself. Six directories were tracked on main but not on the maintenance branch, so a fixed version had no way of reaching it: - npm: edge3 www, fab www, /registry, react plugin template - uv: /dev/breeze - gomod: /go-sdk They now have `target-branch: v3-3-test` entries following the policy the branch already uses for core-ui and auth-ui: minor and patch only, majors ignored. A fix that needs a major bump still has to be backported by hand. `dev/update_github_branch_config.py` generates the same six entries, so cutting the next release branch does not silently reintroduce the gap. (cherry picked from commit 00679b8) Co-authored-by: Jarek Potiuk <jarek@potiuk.com> Generated-by: Claude Opus 5 (1M context)

…red (#70556) (#70597) * Group Dependabot security updates Dependabot groups only apply to security updates when they declare `applies-to: security-updates`; without it a group covers version updates only. Every group in our config relied on that default, so alert-driven bumps bypassed grouping entirely and opened one PR each - axios in edge3 (#70145), mermaid (#69132, #69137), gitpython (#70428), zeep (#68780), @hey-api/openapi-ts (#69265) and the two /go-sdk Go bumps (#70226, #69214). Add a `security-updates` group to every entry that targets the default branch. Entries carrying `target-branch: v3-3-test` are deliberately left alone: Dependabot raises security updates against the default branch only, so a security group there would never match. Comments note this so it does not look like an oversight. The three existing `*-major-version-updates` groups were already `applies-to: security-updates` but restricted to `update-types: [major]`, so minor and patch security fixes fell through ungrouped. They are widened to cover all security updates and renamed to `*-security-updates` to match what they actually do. Also adds a `gomod` entry for /go-sdk, which had no configuration at all - its Go security bumps were arriving individually because Dependabot raises security updates for ecosystems with no entry, but can only group them when one exists. Generated-by: Claude Opus 5 (1M context) * Mirror remaining dependency directories onto v3-3-test Dependabot raises security updates against the default branch only, so a fix that lands on main does not reach a maintenance branch by itself. Cherry-picking one over is unreliable: these commits carry lock file diffs, and main's lock files have long diverged from v3-3-test's, so the pick conflicts more often than not. Letting Dependabot maintain the branch directly avoids that entirely - it resolves the dependency and regenerates the lock file on v3-3-test itself. Six directories were tracked on main but not on the maintenance branch, so a fixed version had no way of reaching it: - npm: edge3 www, fab www, /registry, react plugin template - uv: /dev/breeze - gomod: /go-sdk They now have `target-branch: v3-3-test` entries following the policy the branch already uses for core-ui and auth-ui: minor and patch only, majors ignored. A fix that needs a major bump still has to be backported by hand. `dev/update_github_branch_config.py` generates the same six entries, so cutting the next release branch does not silently reintroduce the gap. (cherry picked from commit 00679b8) Generated-by: Claude Opus 5 (1M context) Co-authored-by: Jarek Potiuk <jarek@potiuk.com>

boring-cyborg Bot added area:dev-tools backport-to-v3-3-test Backport to v3-3-test labels Jul 27, 2026

potiuk force-pushed the group-dependabot-security-updates branch from 9f9490f to fe9b1d7 Compare July 27, 2026 18:42

potiuk requested review from amoghrajesh, ashb, bugraoz93, choo121600, ephraimbuddy, gopidesupavan, jason810496, jedcunningham, jscheffl and vatsrahul1001 as code owners July 27, 2026 18:50

potiuk changed the title ~~Group Dependabot security updates~~ Group Dependabot security updates and keep v3-3-test covered Jul 27, 2026

vincbeck approved these changes Jul 27, 2026

View reviewed changes

kaxil approved these changes Jul 27, 2026

View reviewed changes

potiuk force-pushed the group-dependabot-security-updates branch from 2e0b9ab to b1ade46 Compare July 27, 2026 21:22

potiuk added 2 commits July 28, 2026 09:34

potiuk force-pushed the group-dependabot-security-updates branch from b1ade46 to 5ad43a7 Compare July 28, 2026 07:34

potiuk merged commit 00679b8 into apache:main Jul 28, 2026
156 checks passed

potiuk deleted the group-dependabot-security-updates branch July 28, 2026 12:02

Navigation Menu

Uh oh!

Group Dependabot security updates and keep v3-3-test covered - #70556