ci: bump checkout and setup-go to node24 majors, so the runner stops shimming every job

[ijroth]

Every job in ci.yml and release.yml has been carrying the same warning on every run — actions/checkout@v4 and actions/setup-go@v5 declare runs.using: node20 and the runner substitutes Node 24 behind them. This bumps both to the current major so nothing is being forced any more.

	from	to	why that version
actions/checkout	v4	v7	v7.0.1 is the latest release (2026-07-20); runs.using: node24
actions/setup-go	v5	v7	v7.0.0 is the latest release (2026-07-16); runs.using: node24

Six checkout and five setup-go references, across ci.yml (four jobs) and release.yml (two jobs). Major-tag pinning kept, which is what the repo already uses.

#45 named checkout@v5 and setup-go@v6. Both were a major behind by the time it was filed. I confirmed the current tags against the releases API rather than taking the issue's numbers.

What I checked in the release notes

A green run would not have caught any of these, so they were read rather than inferred:

• checkout v5 — node24, minimum runner v2.327.1. Hosted runners are well past it.
• checkout v6 — Persist creds to a separate file (actions/checkout#2286). The auth token leaves .git/config for a separate file pulled in via includeIf. Nothing in this repo reads that header back: release.yml authenticates gh with GH_TOKEN, not the checkout credential.
• checkout v7 — Block checking out fork PR for pull_request_target and workflow_run (actions/checkout#2454). This is the one that could have broken external contributors, so I read src/unsafe-pr-checkout-helper.ts at the tag: assertSafePrCheckout returns early for every event that is not pull_request_target or workflow_run. ci.yml is pull_request, release.yml is a tag push, and cla.yml — the only pull_request_target workflow here — has no checkout step. Fork PRs still build.
• setup-go v6 — the release notes' only entry flagged Breaking Changes: actions/setup-go#460 sets GOTOOLCHAIN=local, so a go command can no longer silently download a newer toolchain than the one installed. go.mod here pins go 1.26.5 with no toolchain directive, and go-version-file: go.mod installs exactly 1.26.5, so the requirement and the installed toolchain agree and there is nothing left to download.
• setup-go v7 — ESM migration plus @actions/cache 6.2.0. No interface change.

The Windows line-endings job

The job most exposed to a checkout major bump, since it depends on git config --global core.autocrlf true in the step before checkout actually reaching the checkout. checkout relocates HOME to a temporary directory for the duration, so the question is whether the global setting survives that.

It does: configureTempGlobalConfig in src/git-auth-helper.ts at v7.0.1 still copies the existing ~/.gitconfig into the temp home, exactly as v4 did. Worth stating plainly because the failure here would have been silent — if the setting were dropped, no file would arrive with CRLF, the check would find nothing converted, and the job would go green while measuring nothing. I also grepped checkout's source at the tag for autocrlf / eol handling: it has none, in v4 or v7.

Release-workflow risk

release.yml is the one that is not discovered until the next tag, so, explicitly:

• create-release uses checkout only to give gh release view / gh release create a repository context. GH_TOKEN: ${{ github.token }} does that work; the checkout credential is not involved, so the v6 credential relocation cannot reach it.
• binaries is checkout + setup-go + go build + gh release upload. The upload is gh with GH_TOKEN, not an action — no upload-artifact or release action is in the file at all, so the bump cannot touch artifact upload. Cross-compilation is driven by GOOS/GOARCH/CGO_ENABLED=0 in the step env, none of which GOTOOLCHAIN=local affects; setup-go installs the go.mod version and the build runs on it.
• The only new way this workflow could fail is setup-go refusing to satisfy a go.mod requirement it previously papered over with a toolchain download. That would fail on every matrix leg identically, and ci.yml exercises the same setup-go@v7 + go-version-file: go.mod pair on this PR — so CI here is a real rehearsal of the release path's Go setup, not just an adjacent one.

cla.yml left alone, deliberately

#45 called contributor-assistant/github-action@v2.6.1 "not currently flagged". It is flagged — just not on the runs the issue was looking at. It emits the same warning on pull_request_target runs (job 98791685255 on run 33153787749); the issue_comment runs skip the step via its if, which is why it looked clean.

It cannot be fixed by a bump. v2.6.1 (2024-09-26) is the newest release, the default branch's action.yml is node20 as well, and the upstream repository is archived. There is no version to move to, so this needs a replacement rather than a version change — filed as #50.

Verification

Baseline, run 33153787771 on main — all four jobs carried:

Node.js 20 is deprecated. The following actions target Node.js 20 but are being forced to run on Node.js 24: actions/checkout@v4, actions/setup-go@v5.

Post-merge check on this PR's run is recorded in the comments below: annotations pulled per job via /repos/elk-work/ark/check-runs/<job>/annotations, not just a green tick, since a passing run and an annotation-free run are different things and the second one is the point of the issue.

Closes #45

[ijroth]

Annotations checked, not just the tick

CI run 33154345581 — all five checks pass, and annotations pulled per job from /repos/elk-work/ark/check-runs/<job>/annotations:

job	before (run 33153787771)	after
test	Node 20 deprecation	none
windows	Node 20 deprecation	none
keyring-linux	Node 20 deprecation	none
keyring-macos	Node 20 deprecation	none

Zero annotations of any level on all four jobs. The shim is gone, not merely quiet.

release.yml has no run to check — it is tag-triggered — but it uses the same two actions at the same two versions that the four green jobs above just exercised, including the setup-go@v7 + go-version-file: go.mod pair that was the only place a bump could plausibly have bitten it.

The Windows job is still measuring what it claims. This was the failure mode worth ruling out, since a silently-defeated core.autocrlf would have made the check pass by finding nothing:

• before, under checkout@v4: 138 of 138 tracked files pinned to LF, all verified
• after, under checkout@v7: 138 of 138 tracked files pinned to LF, all verified

Identical, so git config --global core.autocrlf true is still reaching the checkout through checkout's temporary HOME.

Still emitting, and expected to: cla-assistant on run 33154345563 carries contributor-assistant/github-action@v2.6.1's own Node 20 warning. Out of scope here for the reason in #50 — the upstream repo is archived, so there is no version to bump to.