ci: modernize release.yml GitHub Actions versions#6
Conversation
Eventic-Autofix: gha_modernize
👤 Will Hattingh — Team Lead — nitecon@gmail.comVERDICT: approve (open for your validate-then-merge — NOT auto-merged) Per your "approve", this opens the branch+PR with the four release.yml action bumps: checkout v4→v6, upload-artifact v4→v7, download-artifact v4→v8, and the highest-risk softprops/action-gh-release v2→v3 (the dual release-creating step). Branched cleanly from origin/main @46d3c70, Team-Lead-authored, no tag/release created. This is a release-only repo — release.yml is tag-gated, so branch CI runs no checks and the bumps cannot be exercised here. Per the agreed plan I am not merging this one: please validate by cutting a release (or a scratch pre-release across the 5.4/5.5/5.6/5.7 UE matrix) to confirm build→upload→download→publish, then merge. The handler will never cut that tag (guardrail). Posted by Eventic (nitecon) on behalf of the Team Lead persona. |
✅ Quality Assurance — qa@runtime-dynamics.orgVERDICT: pass All four targets are real latest-majors (checkout v6.0.3, upload-artifact v7.0.1, download-artifact v8.0.1, action-gh-release v3.0.0); YAML parses. Breaking-change compatibility vs actual usage: upload v7 uses per-matrix unique names (AssetsBridge--UE<5.4|5.5|5.6|5.7>) so the v4 immutability/unique-name rule holds; download v8 uses pattern: AssetsBridge-* + merge-multiple: true (both inputs confirmed present in v8) — upload v7/download v8 are matched-generation; action-gh-release v3 is runtime-only with all used inputs (tag_name/name/body/files/prerelease/make_latest/draft) unchanged. CONCERN (non-blocking): download-artifact v8 newly defaults digest-mismatch to error (was warn), and the full upload→download→release flow + the dual gh-release step can only be confirmed by a real release cut — tag-gated, so untestable in branch CI. No incompatibility evident statically; bumps are likely-correct. Posted by Eventic (nitecon) on behalf of the Quality Assurance persona. |
🛡️ Security Operations — soc@runtime-dynamics.orgVERDICT: pass Tightly scoped to the four stated action bumps in release.yml (plus a cosmetic whitespace edit); no other file touched, no lockfile drift, no scope change. All four are legitimate latest majors of established first-party/well-known actions with no outstanding advisories; the upload v7/download v8 pair is the correctly matched generation. Job permissions remain contents: write (minimal for releases, no escalation); only secret is the standard ephemeral GITHUB_TOKEN; no run: step interpolates bumped-action output into a shell (no new injection sink). Residual (pre-existing repo style, not introduced here): float-tag rather than commit-SHA pinning on the release-creating action — the tag-gated, human-validated flow keeps a person in the loop. Posted by Eventic (nitecon) on behalf of the Security Operations persona. |
1 participant
Modernizes the four outdated GitHub Actions in
.github/workflows/release.yml(the only workflow in this repo). Versions resolved against each action's latest GitHub release as of 2026-06-03.The 4 bumps
actions/checkout@v4->@v6ubuntu-latest. Lowest risk of the set.actions/upload-artifact@v4->@v7AssetsBridge-<tag>-UE<ver>), so the no-same-name-reupload rule is satisfied. A v4->v7 multi-major jump — verify before relying on it.actions/download-artifact@v4->@v8pattern: AssetsBridge-*+merge-multiple: trueintoartifacts/, thenfiles: artifacts/*.zip. v4+ already downloads each artifact to its own subdir and merge-multiple flattens, so likely compatible — confirm the create-release glob still resolves after the v4->v8 jump.softprops/action-gh-releasemake_latestL170@v2->@v3files:globs,tag_name,prerelease/make_latest, and body templating still behave before a real cut.Why this is not auto-merged
release.ymlis the ONLY workflow in this repo and it is tag-gated: thesource-releasejob runs on push tomain, andversion-release+create-releaserun only onpush: tags: v*. A branch/PR push never exercises the tag jobs, so nogh pr checksrun can validate these bumps — this is a release-only repo and the bumps are unverifiable by branch CI.The handler must never cut a tag to test a release, so the only authoritative validation is a real release on your own cadence. Validate-then-merge is yours: apply this branch, then cut a release (or run a scratch/fork pre-release tag across the 5.4/5.5/5.6/5.7 matrix) to confirm the per-UE zips still build, upload, download, and publish before merging.
Branched from
origin/main@ 46d3c70 (v1.3.0 release commit).Eventic-Task: 019e80b9-65f9-7003-8e4c-06592b7843e3