Force node to v24 and bug fixes in the pipelines

[ErikMogensen]

Forced the actions to run to node v24.
Some bug fixes in the pipelines

[Copilot]

Pull request overview

This PR updates GitHub Actions workflows to force JavaScript-based actions to run on Node.js 24, and includes a couple of workflow reliability fixes around tagging and release publishing.

Changes:

• Add FORCE_JAVASCRIPT_ACTIONS_TO_NODE24: true at workflow level across key pipelines.
• Update actions/checkout usage in publish.yml from @v3 to @v4.
• Improve pipeline robustness: fix $GITHUB_OUTPUT usage in handle-tag.yml and avoid failing/duplicating when a GitHub Release already exists in publish.yml.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.

File	Description
.github/workflows/publish.yml	Forces Node 24 for JS actions, upgrades checkout to v4, and makes release creation idempotent by skipping if the release exists.
.github/workflows/handle-tag.yml	Forces Node 24 for JS actions, fixes step output writing to $GITHUB_OUTPUT, and ensures version extraction waits for tag/main verification.
.github/workflows/claude.yml	Forces Node 24 for JS actions for the Claude workflow.
.github/workflows/build-test.yml	Forces Node 24 for JS actions for the build/test reusable workflow.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[ErikMogensen]

@claude, please review this pr

[claude]

Claude finished @ErikMogensen's task in 1m 27s —— View job

---

PR Review: Force node to v24 and bug fixes in the pipelines

• Read changed workflow files
• Analyze changes
• Post review feedback

---

Overall, this is a solid set of fixes. The $GITHUB_OUTPUT corrections are particularly important — the old format was silently broken and job outputs were never being set correctly, which would have caused downstream jobs to behave unpredictably. Everything else is a good incremental improvement.

handle-tag.yml — Critical bug fixes

$GITHUB_OUTPUT format fix (lines 21, 33)

The old format was wrong on both output steps:

# Old (broken)
echo "{name}=tag-hash::${hash}" >> $GITHUB_OUTPUT
echo "{name}=main-hash::${hash}" >> $GITHUB_OUTPUT

# New (correct)
echo "tag-hash=${hash}" >> $GITHUB_OUTPUT
echo "main-hash=${hash}" >> $GITHUB_OUTPUT

The {name}=key::value pattern was a leftover from the deprecated ::set-output command era. The correct modern format is key=value. With the broken format, steps.tag-commit-hash.outputs.tag-hash and steps.main-commit-hash.outputs.main-hash would always be empty strings, making the branch-verification check on line 37 always evaluate to false (i.e., always pass, even for tags not on main). This was a real security/correctness gap — good catch.

needs: [check-tag-branch] added to get-version (line 43)

Before this change, get-version ran concurrently with check-tag-branch. If the tag was not on main, check-tag-branch would fail, but get-version (and subsequently call-build-test and publish-it) could still be triggered in parallel since they only declared needs: [check-tag-branch, get-version] — not a strict sequential dependency on check-tag-branch completing first. Adding needs: [check-tag-branch] to get-version properly gates the entire pipeline. Correct fix.

publish.yml — Idempotent release creation

Replacing continue-on-error: true with explicit existence check (lines 86–92)

$releaseExists = gh release view ${{ env.RELEASE_VERSION }} 2>&1
if ($LASTEXITCODE -ne 0) {
  gh release create ${{ env.RELEASE_VERSION }} --draft --generate-notes
} else {
  echo "Release ${{ env.RELEASE_VERSION }} already exists, skipping creation."
}

This is better than continue-on-error: true because it only swallows the "release already exists" case rather than silently ignoring all errors (permissions issues, API failures, etc.). The logic is correct — $LASTEXITCODE is the right check here for PowerShell.

Minor style note: $releaseExists is assigned but its content is never used — only $LASTEXITCODE matters. Could optionally redirect output to $null instead (gh release view ... > $null 2>&1), but this works fine as-is.

One potential edge case: if this workflow is triggered twice for the same tag and the first run already uploaded release assets, the second run's gh release upload step (line 99–100) could fail with a duplicate-asset error, since continue-on-error was only removed from the create step. This is an uncommon scenario, but worth being aware of.

actions/checkout@v3 → @v4 (line 28)

Standard upgrade. v3 uses Node.js 16 (deprecated) while v4 uses Node.js 20. This is a necessary bump and pairs well with FORCE_JAVASCRIPT_ACTIONS_TO_NODE24.

build-test.yml, claude.yml, handle-tag.yml, publish.yml — FORCE_JAVASCRIPT_ACTIONS_TO_NODE24

Setting FORCE_JAVASCRIPT_ACTIONS_TO_NODE24: true at workflow level is the correct approach to suppress Node.js deprecation warnings from older bundled actions. All four workflows apply it consistently.

Summary

Change	Assessment
Fix broken $GITHUB_OUTPUT format	✅ Critical correctness fix
Add needs: [check-tag-branch] to get-version	✅ Important pipeline gate fix
Idempotent release creation	✅ Robustness improvement
checkout@v3 → @v4	✅ Dependency upgrade
FORCE_JAVASCRIPT_ACTIONS_TO_NODE24: true	✅ Correct deprecation fix

Recommendation: Approve and merge. No blocking issues found.