ci(release): fold deploy-intent check into tag_info step (fix startup failure from #303)#307
Merged
Merged
Conversation
Follow-up to #303. The env-based approach in that PR triggered a GHA startup failure (workflow accepted, 0 jobs scheduled, run completed in the same second with conclusion=failure) because a step-level `env:` value cannot safely carry the multi-line `tag_message` output — GHA rejects the workflow at dispatch time. Verified failure signature on 8eae29e: run 28627254564 / 28627293599 — status=completed, conclusion=failure, jobs=[], run_started_at == updated_at (single-second dispatch reject). Fix: perform the `[no-deploy]` grep INSIDE the `Get tag information` step, where `$TAG_MESSAGE` already exists as a plain bash variable. Export the single-line `draft` boolean from the same step. The multi-line `tag_message` output is preserved (still consumed by the release-body heredoc, which is safe because it uses `<<'EOT'`). Update the two downstream references from steps.deploy_check.outputs.draft to steps.tag_info.outputs.draft. Root cause and reasoning preserved as an inline comment. Signed-off-by: Matee ullah Malik <mateeullahmalik@hotmail.com>
j-rafique
approved these changes
Jul 3, 2026
mateeullahmalik
added a commit
that referenced
this pull request
Jul 6, 2026
Follow-up to #307. The comment added in that PR contained the literal text '${{ }} interpolation' inside a run: bash block. GitHub Actions validates ${{ ... }} expressions everywhere in the workflow file at dispatch time — including inside bash comments in run: block scalars. An empty ${{ }} expression is a validation error, so every push to master (and every tag push) since #307 landed hits a workflow startup failure: run accepted, 0 jobs scheduled, run_started_at == updated_at, conclusion=failure. Verified failure signature on ea1a9c4 (post-#307 master): run 28756586178 / 28756630521 — status=completed, conclusion=failure, jobs=[], run_started_at == updated_at. Also observed on tag push of v2.6.0-testnet retagged onto ea1a9c4: the release job never scheduled, so assets remained empty. Fix: rephrase the comment to describe the prior pattern in English rather than embedding the literal syntax. No functional change to any step logic. Signed-off-by: Matee ullah Malik <mateeullahmalik@hotmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Follow-up to #303. That PR moved the tag-message into a step-level
env:block to avoid shell-expanding a multi-line value intorun:. Unfortunately GHA rejects that shape at workflow dispatch time — a multi-line output cannot be plumbed into another step'senv:— so thereleasejob never got scheduled.Evidence the previous fix failed to run
Runs on the post-merge master SHA
8eae29e(Build and Release Workflow, id163702778):28627254564— statuscompleted, conclusionfailure, jobs=[],run_started_at == updated_at(dispatched and closed in the same second)28627293599— same signature28615651344This is the classic GHA startup-failure fingerprint: the workflow file parses, but the job graph is refused at scheduling.
Fix
Perform the
[no-deploy]grep inside theGet tag informationstep, where$TAG_MESSAGEalready exists as a plain bash variable, and export the single-linedraftboolean from the same step. The multi-linetag_messageoutput is still emitted (the release-body heredoc consumes it via<<'EOT', which is safe).Two downstream references are updated from
steps.deploy_check.outputs.draft→steps.tag_info.outputs.draft.Why this is safer than #303
env:binding to a multi-line output (which is what tripped the scheduler).[no-deploy]semantics are byte-identical (same case-insensitive grep).draftoutput is a fixedtrue/falsestring — always single-line, always safe to consume via${{ }}.Blast radius
.github/workflows/build&release.ymlonly.softprops/action-gh-releasestep, or release-body composition.release-bodyheredoc (line ~208) still uses<<'EOT'and continues to referencesteps.tag_info.outputs.tag_messagesafely (quoted heredoc suppresses expansion — this was true before and remains true).Verification
python3 -c "import yaml; yaml.safe_load(open('.github/workflows/build&release.yml'))"→ OK, jobs['build', 'release'].v2.6.0-testnetat the new master HEAD and confirm CI produces a completedreleasejob withsupernode-linux-amd64.tar.gz+supernode-linux-amd64attached to the existing release.Rollback
Revert the commit. No state involved.
Post-merge plan
v2.6.0-testnetat new master → CI'sUpload assets to existing releasepath attaches the two artifacts to the existing release (preserving the release notes)../testnet_version_check.shon the fleet to verifysn-managerpicks it up on the 15 healthy SNs.