Skip to content

Chore(ci): enable Dependabot npm version updates (stacked on #650) - #757

Open
AmaadMartin wants to merge 1 commit into
feat/dependabot-github-actions-updatesfrom
feat/dependabot-npm-version-updates
Open

Chore(ci): enable Dependabot npm version updates (stacked on #650)#757
AmaadMartin wants to merge 1 commit into
feat/dependabot-github-actions-updatesfrom
feat/dependabot-npm-version-updates

Conversation

@AmaadMartin

@AmaadMartin AmaadMartin commented Aug 7, 2026

Copy link
Copy Markdown
Owner

Please ensure you have read the contribution guide before creating a pull request.

Link to Issue or Description of Change

  1. Link to an existing issue (if applicable):

No issue.

  1. Or, if no issue exists, describe the change:

Problem: Dependabot already raises npm security updates here with no configuration file: google/adk-js#448, #443, #434, #428, #396, #329, #297 are all titled chore: Bump the npm_and_yarn group .... Version updates are different. They require a committed .github/dependabot.yml, so they never run. The dependency tree only moves when an advisory forces it, and routine patch drift accumulates into a large manual catch-up.

Solution: Add one npm entry to the .github/dependabot.yml that #650 introduces. Minor and patch bumps land as a single grouped PR each week. Majors match no group rule, so each one opens on its own and a breaking bump cannot hold back the safe bumps beside it.

Scope

Stacked on #650 (feat/dependabot-github-actions-updates), which adds the file and the github-actions entry, and which explicitly deferred npm. One file changes, 17 added lines and 1 reworded header comment. Nothing under .github/workflows/ is touched, so this stays independent of the action SHA-pinning work (#505, #613) and the workflow-permissions work (#649). package.json and package-lock.json are untouched; I ran no install.

Key-by-key reasoning

Key Value Why
package-ecosystem 'npm' Schema enum member. Covers npm and the root package-lock.json.
directory '/' The root manifest reaches the workspace members. The file list of google/adk-js#448 is exactly package.json, core/package.json, dev/package.json, package-lock.json, so a root-anchored run is already workspace-aware here. Listing /core, /dev and /integrations would be wrong: they hold no lockfile, and the docs forbid overlapping directories for one ecosystem.
schedule.interval 'weekly' Matches the sibling entry. The tree carries 94 direct declarations across 4 manifests; daily is noise and monthly lets drift pile up.
groups.…patterns ['*'] One rule, every package.
groups.…update-types ['minor', 'patch'] The one divergence from the '*' catch-all #650 uses for actions. With 94 declarations, a breaking major inside the weekly group blocks every safe bump in the same PR. Majors match no rule, so the docs say they open individually, each with its own CI result.
commit-message.prefix 'chore(deps)' Same as the sibling entry. release-please-config.json sets "release-type": "node", which parses conventional commits, so chore keeps dependency bumps out of the release notes.

Security updates only, or all versions?

All versions. A "security only" entry cannot be expressed: the sole spelling is open-pull-requests-limit: 0, which the docs describe as disabling version updates. Since npm security updates already run configuration-free (the PR list above), that entry would change nothing. Grouping is the noise control instead.

Keys deliberately omitted

  • versioning-strategy — the default auto already produces increase-style caret bumps in this repo. Evidence from the google/adk-js#448 diff: "^0.205.0" -> "^0.220.0" and "^6.6.6" -> "^7.1.6", with no widened >=x <y ranges. Setting increase would restate observed behaviour.
  • open-pull-requests-limit — the documented default is 5, which is the right cap here: the grouped PR plus at most four majors.
  • cooldown — a 3-day default already applies to version updates.
  • ignore, allow, labels, assignees, reviewers, registries, dependency-type — not required. target-branch would actively harm: setting it detaches this ecosystem's options from security updates.

Disclosed side effect

commit-message also applies to security updates. Existing npm security PR titles change from chore: Bump the npm_and_yarn group ... to chore(deps): Bump .... Still a non-releasable chore, but it is externally visible. Grouped security updates are unaffected, because groups.applies-to defaults to version updates.

Collision check

gh pr list --repo AmaadMartin/adk-js --state all --limit 400 plus gh search prs --repo AmaadMartin/adk-js --state open "dependabot.yml". Only #650 touches .github/dependabot.yml, and it is this stack's base. #684 and #688 carry "Dependabot" in the title but bump packages; gh pr diff --name-only confirms neither touches the config. #507 and #613 matched the text search and touch neither the file nor the ecosystem.

Testing Plan

Please describe the tests that you ran to verify your changes.

Unit Tests:

[ ] I have added or updated unit tests for my change.
[ ] All unit tests pass locally.

I left both boxes unchecked on purpose. No unit test file exists for this change, and adding one would be wrong. The diff has zero lines of executable code, so there is no line, branch or function coverage to add. vitest.config.ts scopes coverage to core/src/**, dev/src/** and integrations/src/**, so a file under .github/ cannot move the thresholds. No repository-configuration test category exists under core/test/, dev/test/, integrations/test/ or tests/; inventing one would assert GitHub's schema rather than adk-js behaviour.

Four checks stand in its place. All four pass on c5687e51:

# Command Result
1 npx js-yaml .github/dependabot.yml exit 0
2 node + assert/strict over the parsed document (version, ecosystem order, directory, interval, group patterns, update-types, prefix, and the absence of versioning-strategy and open-pull-requests-limit) dependabot.yml OK
3 npx ajv-cli@5 validate -s dependabot-2.0.json -d .github/dependabot.yml --spec=draft7 --strict=false .github/dependabot.yml valid
4 npx secretlint ".github/dependabot.yml" and bash scripts/check_license.sh exit 0 and exit 0. check_license.sh scans only *.js and *.ts, so the YAML is out of its scope — I verified that in the script rather than assuming it.

Each check was proved able to fail. I applied each mutation, recorded the failure, then restored the file and confirmed it was byte-identical by sha256sum:

Mutation Check Failure
A: directory: '/' -> '/core' 2 fails, 3 still passes expected: '/', operator: 'strictEqual'. The schema types directory as an unconstrained string, so check 3 cannot see this. That is why check 2 exists.
B: package-ecosystem: 'npm' -> 'npm_and_yarn' 3 fails must be equal to one of the allowed values at #/definitions/package-ecosystem-values/enum. Confirms npm is the enum member, not the group name Dependabot prints in PR titles.
C: delete the group's update-types list 2 fails expected: [ 'minor', 'patch' ], operator: 'deepStrictEqual'. Pins the majors-stay-individual decision against a later silent edit.

No test CI runs on this PR, and that is expected. validation.yaml and license-check.yml both trigger on pull_request: branches: [main] only. This PR targets feat/dependabot-github-actions-updates, so neither workflow starts; the only check that ran is auto-assign, which validates nothing. Retargeting to main after #650 merges will run both.

I validated locally on the pushed commit c5687e51 instead. The four checks above are the substitute, and they are the complete substitute: no other repository script can observe this file. Per the root package.json, lint is eslint "**/*.ts", format:check is prettier "**/*.ts" --check, build is npm run build --workspaces over the three src trees, and every vitest project reads core/test, dev/test, integrations/test or tests/. None of them glob .github/. The two CI steps that do see the file are npx secretlint "**/*" and bash scripts/check_license.sh, and both are check 4 above.

Manual End-to-End (E2E) Tests:

An end-to-end test cannot run before merge. Dependabot reads .github/dependabot.yml from the default branch only, and version updates are not auto-enabled on forks. After merge:

  1. Open Insights -> Dependency graph -> Dependabot. Expect a row for github-actions and a row for npm, each with a "Last checked" time and no red configuration-error banner. That banner is the authoritative signal that the file is wrong.
  2. Within a week, expect one PR titled about chore(deps): bump the npm-minor-and-patch group with N updates, plus a separate PR per outstanding major, capped at five open version-update PRs.
  3. Confirm the grouped PR touches only package.json, core/package.json, dev/package.json, integrations/package.json and package-lock.json. The 14 tests/integration/** manifests are not workspace members and declare only file: links, so there is no registry version to bump. If one is ever touched, the remedy is a single ignore rule.
  4. A release published in the last 3 days may be missing from the first sweep. That is the default version-update cooldown, not a fault.

Checklist

[x] I have read the CONTRIBUTING.md document.
[x] I have performed a self-review of my own code.
[x] I have commented my code, particularly in hard-to-understand areas.
[x] I have added tests that prove my fix is effective or that my feature works. (The four configuration checks above, each proved able to fail.)
[ ] New and existing unit tests pass locally with my changes. (I ran no unit test: the diff contains no executable code and no test covers .github/.)

Security updates already run on this repository without a configuration
file. Version updates do not: they require .github/dependabot.yml. The
dependency tree therefore only moves when an advisory forces it.

Add a second updates entry for the npm ecosystem at the repository root.
Minor and patch bumps are grouped into one weekly pull request. Majors
match no group rule, so each opens on its own and a breaking bump cannot
hold back the safe ones.
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