gofr-dev / gofr-dev/gofr

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

Open
#3,872 1 comment 0 reactions 0 assignees View on GitHub
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.