CI: GitHub Actions pins are 1-2 majors behind (upload-artifact bump touches the SignPath release path)

[erikdarlingdata]

Found by the 2026-07 maintenance pass (#1643). Split out of PR #1645 because these are major bumps and one of them reaches the release-signing path.

Checked against the GitHub releases API (not a search summary) on 2026-07-25:

Action	Pinned	Latest	Behind
actions/checkout	v5	v7	2 majors
actions/setup-dotnet	v5	v6	1 major
actions/cache	v4	v6	2 majors
actions/upload-artifact	v6	v7	1 major
dorny/paths-filter	v3	v4	1 major
signpath/github-action-submit-signing-request	v2	v2	current

Used across build.yml, nightly.yml, sql-validation.yml, check-pr-branch.yml, and check-version-bump.yml.

Why this is not a drive-by bump

actions/upload-artifact is not just build plumbing here. Its artifact-id output feeds directly into all six signpath/github-action-submit-signing-request steps in build.yml:

github-artifact-id: '${{ steps.upload-lite.outputs.artifact-id }}'

v7 introduces uploading non-zipped artifacts (the archive parameter). SignPath consumes the uploaded artifact by id and expects a particular artifact shape per its artifact-configuration slugs (Lite, Darling, DarlingViewer). If the artifact format or the id semantics shift, signing breaks — and it breaks at release time, on the release: [published] trigger, which is the worst moment to discover it.

actions/cache v6 also matters for the pg-runtime.zip caching (a ~340MB pinned EDB/TimescaleDB download); a cache-key or restore-behavior change means a slow release build rather than a broken one.

Suggested approach

1. Bump the low-risk, build-only ones first and let normal PR CI prove them: dorny/paths-filter v3 -> v4, actions/cache v4 -> v6, actions/setup-dotnet v5 -> v6, actions/checkout v5 -> v7. All are exercised by every PR run, so a break is immediately visible and contained.
2. Handle actions/upload-artifact v6 -> v7 separately, and validate it against a real signing run before trusting it — the release path is the only place those steps execute. Read the v7 release notes for the archive default and confirm SignPath's expectations before merging.

Note the runner requirement that came with upload-artifact v6 (Node 24, minimum runner 2.327.1). GitHub-hosted windows-latest satisfies this; it would only matter if self-hosted runners are ever introduced.

[erikdarlingdata]

Heads-up: #1644 merged to dev shortly before this was filed, enabling Dependabot version updates — and it configures the GitHub Actions ecosystem as a single grouped PR:

  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"
      day: "monday"
    groups:
      github-actions:
        patterns:
          - "*"

So starting the next Monday run, Dependabot will open one PR bundling all of the bumps in the table above — including actions/upload-artifact v6 -> v7.

That is precisely the bundling this issue recommends against. The four build-only bumps (checkout, setup-dotnet, cache, paths-filter) are proven by any normal PR run. upload-artifact is not: its steps only execute on release: [published], it feeds artifact-id into all six SignPath signing steps, and v7 changes artifact packaging. In a grouped PR, green CI will look like proof that the whole group is safe, when the release-signing half was never exercised at all.

Two options:

1. Exclude upload-artifact from the group so it arrives as its own PR — e.g. add exclude-patterns: ["actions/upload-artifact"] to the github-actions group, or give it a dedicated group.
2. Leave the config alone, but treat any grouped Actions PR that contains upload-artifact as release-gated: split that hunk off and validate it against a real signing run before merging.

Either way the important thing is that a green check on the grouped PR must not be read as clearance for the signing path.

[erikdarlingdata]

Fixed by PR #1671, merged to dev. Live on DARLING01 as of the dev@f899fe94 deploy (2026-07-26).