CI: Dependabot cannot see node-version/go-version in setup-* steps, which is how #3870 happened

[akshat-kumar-singhal]

Summary

Dependabot's github-actions manager updates the uses: action reference but not the with: inputs that select a language runtime. So node-version:, go-version:, and python-version: values are invisible to our current dependency automation and can silently go end-of-life.

This is not hypothetical — it is exactly how #3870 happened, and this repo contains the proof.

The evidence

Before #3871, website-prod.yml and website-stage.yml looked like this:

- name: Setup Node.js
  uses: actions/setup-node@v7      # <- current major. Dependabot kept this fresh.
  with:
    node-version: 18.x             # <- EOL 2025-04-30. Dependabot never touched it.

Two lines apart. Dependabot had been doing its job on the line above for years while the line below rotted past end-of-life. Every action in the repo is on a current major — actions/checkout@v7, actions/setup-go@v7, actions/setup-node@v7, actions/upload-artifact@v7, actions/download-artifact@v8 — which is what makes this a clean natural experiment rather than a guess: the manager was demonstrably running and demonstrably could not see the runtime version.

#3871 fixed the values (18.x → 24.x). It did nothing about the mechanism, so the same drift will recur on the same schedule.

Why Renovate is the relevant difference

Per Renovate's github-actions manager docs:

Renovate supports updating the with version for actions/setup-go, actions/setup-node, and actions/setup-python, although not all syntaxes are supported out of the box.

Renovate will use npm-style semver versioning for go and python, and Renovate's built-in node versioning for updating node.

Dependabot has no equivalent. As far as I can find there is no Dependabot configuration that closes this — it is a capability gap in the manager, not a setting we have wrong.

Options

1. Adopt Renovate for the github-actions manager (either alongside Dependabot for gomod, or replacing it wholesale). Closes this properly and also covers the Docker gap in the companion issue.
2. A CI guard instead — a small scheduled job that reads nodejs/Release's schedule.json and fails if any node-version: in .github/workflows/ is past its EOL date. Cheaper and no new bot, but bespoke and only covers Node.
3. Accept and calendar it. Node 24 is supported until 2028-04-30, so the next forced action is far out — but this is what we chose implicitly last time, and it cost us a year on an unsupported runtime.

I'd suggest (1), since the companion issue needs Renovate's Docker manager anyway and doing both at once is one decision rather than two.

Happy to raise the PR for whichever direction maintainers prefer.

Context

Found while fixing #3870 / #3871 and auditing whether the fix would hold.

[adarshjnv9100]

Hi @akshat-kumar-singhal,

I’d like to work on this issue and would appreciate it if you could assign it to me.

I’ve reviewed the issue and understand that the main problem is not the current Node.js version itself, but the fact that Dependabot’s github-actions manager does not reliably update runtime versions specified through with: inputs such as node-version, go-version, and python-version.

My proposed workflow would be:

1. Audit the current CI/dependency configuration

   • Review .github/dependabot.yml.
   • Inspect all workflows under .github/workflows/.
   • Identify every actions/setup-node, actions/setup-go, and actions/setup-python usage.
   • Record the runtime versions currently specified through node-version, go-version, and python-version.

2. Verify the current Dependabot behavior

   • Confirm which dependencies Dependabot currently manages.
   • Verify that action references such as actions/setup-node@... are updated while the corresponding runtime version inputs are not.
   • Check whether there is any existing Dependabot configuration that could address this before introducing another dependency-management tool.

3. Evaluate the proposed solutions

   • Investigate whether Renovate can manage the runtime versions used by the setup actions.
   • Check how Renovate's github-actions manager handles node-version, go-version, and python-version.
   • Review the existing dependency-management setup so that Renovate and Dependabot do not create conflicting or duplicate updates.
   • Consider the CI-guard approach as an alternative if maintainers prefer not to introduce Renovate.

4. Implement the maintainer-approved approach

   • If Renovate is selected, add the minimal required Renovate configuration and configure the relevant managers so that runtime versions inside GitHub Actions are also kept up to date.
   • If a CI guard is preferred, implement a focused scheduled check that detects unsupported runtime versions and fails/reports appropriately.
   • Avoid changing unrelated CI configuration.

5. Test the solution

   • Validate the configuration locally where possible.
   • Check that existing workflows remain valid.
   • Verify that the chosen solution detects or updates runtime versions as intended.
   • Ensure Dependabot/Renovate do not generate conflicting updates if both are retained.

6. Document the behavior

   • Add or update documentation/configuration comments explaining which tool is responsible for maintaining action versions and language runtime versions.
   • Clearly document any limitations or responsibilities that remain manual.

7. Submit a focused PR

   • Keep the changes limited to dependency/CI automation.
   • Explain the problem, why the selected approach solves it, and how it prevents another occurrence of the issue described in CI: website deploy workflows build on Node 18, EOL since 2025-04-30 #3870.
   • Reference #3872 in the PR.

I would first confirm the preferred direction with the maintainers before making a larger tooling change such as adopting Renovate.

I’m happy to take this up. Please assign the issue to me. Thanks!