CI: Dependabot cannot see node-version/go-version in setup-* steps, which is how #3870 happened
- Dominant language
- Go
- Stars
- 20.9k
- Forks
- 1.8k
- Avg merge
- 5d 18h
- Merged PRs (30d)
- 39
Description
### 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:
```yaml
- 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](https://docs.renovatebot.com/modules/manager/github-actions/):
> 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.
Contributor guide
Research direction
Start by reviewing .github/workflows/ and the Renovate github-actions manager documentation, then compare the proposed Renovate adoption with the scheduled Node EOL guard. Done should mean runtime versions selected by setup-node, setup-go, and setup-python no longer silently drift past support, with the chosen approach documented and tested in CI.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- github-actions, go, node.js, python
- Domain
- ci-cd, devops
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 38/100