Update GitHub Actions to Node 24 majors, install nats-server via shared action

[scottf]

The four build workflows pin action majors that still declare node20, so runs log:

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, actions/setup-java@v4, gradle/actions/setup-gradle@v4.

(Seen on https://github.com/nats-io/nats.java/actions/runs/32369985188.)

I checked each action's runs.using against the live repos and bumped them to the first major that declares node24:

action	was	now
actions/checkout	v4	v5
actions/setup-java	v4	v5
gradle/actions/setup-gradle	v4	v5
actions/setup-go	v5	removed — see below

Applied to branch-snapshot.yml, build-main.yml, build-pr.yml and build-release.yml.

coverallsapp/github-action@v2 is a composite action with no Node runtime of its own, which is why it isn't in the warning list — left alone. claude.yml calls a reusable workflow in synadia-io/ai-workflows, so its actions are that repo's concern.

nats-server now installs via the shared action. Each workflow had its own inlined clone-and-build block; those are replaced with synadia-io/workflows/.github/actions/install_nats_server@main, matching what v3 does. That composite action calls go build directly and relies on the Go preinstalled on the runner image, so actions/setup-go comes out entirely — which is both one less action to keep current and 17 lines of duplicated shell removed per workflow.

Dropping setup-go also makes a GOTOOLCHAIN problem disappear. setup-go@v6 unconditionally exports GOTOOLCHAIN=local, which would have meant the nats-server build failing rather than fetching a toolchain when its go.mod asks for one newer than the installed Go. With setup-go gone nothing sets the variable, so it defaults to auto. That matters concretely right now: the ubuntu-24.04 image ships Go 1.26.6 while nats-server declares toolchain go1.26.7, so the build does fetch a toolchain — correct under auto, and it would have been a hard failure under local.

gradle/actions@v6 deliberately skipped. v6 extracts the caching logic into gradle-actions-caching, a proprietary non-MIT component, and the release notes state that upgrading constitutes accepting Gradle's Terms of Use. Caching is on by default in setup-gradle, so v6 would pull a commercial component into every build of an Apache-2.0 repo. v5 is node24 and still fully MIT, so it clears the deprecation without raising the license question. Happy to revisit if we decide the terms are fine.

Newer majors exist for the others (checkout v7, setup-java v6) but they're ESM and dependency refreshes that buy us nothing here. checkout v7 additionally blocks fork-PR checkout under pull_request_target, which is worth steering clear of for now.

One thing to note for review: install_nats_server is referenced at @main, as it is in v3. synadia-io/workflows has no tags or releases, so a branch ref is the only option short of pinning a commit SHA — meaning the install step can change without a PR here. Fine given it's our own repo, but worth being deliberate about.

This isn't urgent — the warning is non-fatal and GitHub is already force-running these on Node 24 — but the node20 runtime does go away eventually.

🤖 Generated with Claude Code

[synadia-claude-reviewer]

Claude finished @scottf's task in 52s —— View job

---

PR Review: Update GitHub Actions to Node 24 Compatible Majors

• Gather context and read PR diff
• Review changes for correctness, security, and behavioral implications

---

This is a clean, well-documented maintenance change. The version bumps are applied consistently across all four workflow files and the PR description thoroughly justifies each choice. No correctness bugs or security issues found.

One item worth making explicit:

setup-go@v6 sets GOTOOLCHAIN=local

The PR description flags this in passing, but it deserves a concrete risk statement: with GOTOOLCHAIN=local, if nats-server's go.mod ever declares a go directive requiring a toolchain newer than whatever go-version: stable resolves to at that moment, the nats-server build step will fail instead of auto-fetching the required toolchain as it does today. The current state (go1.27.0 stable vs nats-server's go 1.26.0 minimum) is fine, but this is a latent trip-wire on the nats-server upgrade path. Adding env: GOTOOLCHAIN: auto to the "Setup GO" step proactively would eliminate that risk with no downside — worth considering even if not strictly necessary right now.

Everything else looks correct:

• Version bumps are identical across all four files — no drift between workflows.
• Skipping gradle/actions@v6 due to the proprietary caching component and MIT-license concern is the right call for an Apache-2.0 project.
• checkout@v5 is safe; the pull_request_target restriction the PR mentions applies to v7, not v5.
• coverallsapp/github-action@v2 and claude.yml are correctly left untouched.

The suggestion in the PR description to add a .github/dependabot.yml github-actions ecosystem entry is worth following up on to prevent this class of drift in the future.

[scottf]

Took the GOTOOLCHAIN suggestion — done in 1e7ceb5 — but the placement needed to change, so flagging it here for anyone reading later.

Adding env: GOTOOLCHAIN: auto to the Setup GO step, as suggested, would not have worked. setup-go@v6's setGoToolchain() runs unconditionally: it ignores any pre-existing GOTOOLCHAIN and calls core.exportVariable('GOTOOLCHAIN', 'local'), which writes to $GITHUB_ENV and so applies to every subsequent step. A step-level env on the Setup GO step only affects that action's own process, and the exported local would still have been in force by the time go build ran in the next step.

So the override sits on the Install Nats Server step instead — the one that actually runs go build — where step-level env takes precedence over what a prior step exported to $GITHUB_ENV. Applied to all four workflows.