.github/workflows/release-main.yml (2)

37-40: ⚠️ Potential issue | 🔴 Critical

Stale semantic-release outputs — the producing step was removed but the outputs: block remains.

Lines 37-40 still map released / release_tag / release_sha from steps.release_state.outputs.*, but the Capture Release State step (id: release_state) was removed from this job. These outputs will therefore always evaluate to empty strings, which silently breaks every downstream consumer — in particular backport-release at lines 95 and 119-120.

See the consolidated comment on backport-release below for the full impact and a proposed direction.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.github/workflows/release-main.yml around lines 37 - 40, The outputs block
still maps released, release_tag, and release_sha from
steps.release_state.outputs.*, but the producing step (id: release_state) was
removed so these will be empty and break consumers like the backport-release
step; fix by either restoring the Capture Release State step with id
release_state that sets those outputs or by removing the
released/release_tag/release_sha entries from the job outputs and updating
downstream references (e.g., the backport-release step) to use an alternative
source; ensure references to steps.release_state and the three output names
(released, release_tag, release_sha) are reconciled across the workflow.

---

93-134: ⚠️ Potential issue | 🔴 Critical

backport-release is broken: stale if:, missing outputs, and reference to a removed job.

After this PR, three compounding issues prevent this job from ever running successfully:

1. if: on line 95 references two things that no longer exist:

   • needs.semantic-release.outputs.released — always empty (see comment on lines 37-40; the release_state step was removed).
   • needs.publish-release.result — publish-release is not in needs (line 96) and has been moved to publish-release.yml (a different workflow, triggered by the release event). Cross-workflow job results are not accessible via needs.*.result. This sub-expression will never be 'success'.

   Net effect: the condition is permanently false, so backport-to-develop is silently disabled on every release.

2. RELEASE_SHA / RELEASE_TAG on lines 119-120 would be empty strings even if the if were fixed, so git cherry-pick -x "" fails and ${RELEASE_TAG#v} is empty.

3. Even with outputs restored, gating on publish-release success is no longer possible from this workflow. You likely need to either (a) move backport-release into publish-release.yml so it can depend on build-and-release, or (b) keep it here but drop the cross-workflow gating and derive tag/sha from git describe / the latest v* tag created by semantic-release.

🛠 Suggested direction (option A: move backport to the on-release workflow)

In publish-release.yml, add a job that needs build-and-release and uses github.event.release.tag_name / github.sha directly — no outputs required. Then delete backport-release from release-main.yml.

Option B (keep here) would look roughly like:

   backport-release:
     name: Backport Release Commit to Develop
-    if: ${{ needs.semantic-release.outputs.released == 'true' && needs.publish-release.result == 'success' }}
+    if: ${{ needs.semantic-release.outputs.released == 'true' }}
     needs: [semantic-release]

and restoring the Capture Release State step (or equivalent) in semantic-release so the three outputs are populated again. Note this loses the prior guarantee that the image was published before backporting.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.github/workflows/release-main.yml around lines 93 - 134, The
backport-release job is disabled by a stale if condition and missing outputs;
fix by either moving the backport-release job into the publish-release.yml
workflow (so it can need build-and-release and read
github.event.release.tag_name and github.sha directly) or, if you keep
backport-release in this file, remove the broken if (the expression referencing
needs.semantic-release.outputs.released and needs.publish-release.result) and
instead derive RELEASE_TAG/RELEASE_SHA inside the job (e.g., use git fetch
--tags && RELEASE_TAG="$(git describe --tags --abbrev=0 --match 'v*')" and
RELEASE_SHA="$(git rev-list -n1 ${RELEASE_TAG})") before running git cherry-pick
-x; ensure the job uses the backport-release name and that the environment vars
RELEASE_TAG and RELEASE_SHA are set from these commands (or restore the
release_state step to populate outputs if you prefer to gate on semantic-release
outputs).

.github/workflows/release-main.yml (1)

83-91: ⚠️ Potential issue | 🔴 Critical

Releases created via GITHUB_TOKEN will not trigger publish-release.yml.

With publish/notify jobs moved to .github/workflows/publish-release.yml (which triggers on release: types: [released]), the entire stable build and Discord notification chain now depends on the GitHub release event firing downstream.

When RELEASE_BOT_TOKEN is unset, the fallback github.token is used. Per GitHub Actions docs, events triggered by the default GITHUB_TOKEN (other than workflow_dispatch/repository_dispatch) do not start new workflow runs. Result: semantic-release publishes the GitHub release, but publish-release.yml never runs — no image is built, no Discord notification sent, and this failure is silent.

Required safeguards:

• Fail fast in this workflow if secrets.RELEASE_BOT_TOKEN is empty. This is now a hard dependency, not a soft fallback, since the cross-workflow trigger is load-bearing.
• Alternatively, add workflow_dispatch trigger to publish-release.yml so a missing PAT doesn't silently skip the build/notify chain.

Manual release creation via the GitHub UI is unaffected — that path is a user event and will trigger publish-release.yml correctly. The risk is strictly for semantic-release-driven releases on main.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.github/workflows/release-main.yml around lines 83 - 91, The workflow
currently falls back to GITHUB_TOKEN which cannot trigger downstream workflows;
update the "Run semantic-release" step to fail fast when
secrets.RELEASE_BOT_TOKEN is empty by adding a pre-check that exits non-zero if
the secret is unset (i.e., verify secrets.RELEASE_BOT_TOKEN and stop the job
instead of assigning GH_TOKEN/GITHUB_TOKEN fallback), and ensure the env for the
step uses only RELEASE_BOT_TOKEN (GH_TOKEN/GITHUB_TOKEN should not be used as a
fallback); alternatively, add a workflow_dispatch trigger to publish-release.yml
so releases can be retriggered manually if the PAT is missing.