PREQ-8689: Create release tags via draft GitHub release

[tomverin]

Summary

• Release of sonar-scanner-cli-docker fails at Create and push release tag with GH013: Cannot create ref due to creations being restricted (git tag + git push of 12.2.0.3249_8.1.0). The tag was never created.
• Replace that git-protocol tag push with the documented draft-first flow: gh release create --draft --target "$GITHUB_SHA" (same pattern as gh-action_release v7). Existing drafts are reused so a later step failure can be retried; a published immutable release is rejected.
• gh-action_sbom@v3 still attaches the SBOM to the draft; gh release edit --draft=false still publishes.

Jira: PREQ-8689

Test plan

• Confirm no GitHub release or tag exists for 12.2.0.3249_8.1.0 (none after the failed run).
• After merge to master, dispatch Actions → Release with tag_name=12.2.0.3249_8.1.0.
• Create or reuse draft release succeeds and creates a draft for that tag at $GITHUB_SHA.
• SBOM is attached to the draft; promote / Docker Hub / publish complete.
• Re-running the same workflow while the release is still a draft reuses it instead of failing.

[hashicorp-vault-sonar-prod]

PREQ-8689

[tomverin]

@sonarsource/code-orchestration-ci-experience-squad @antoine-vinot-sonarsource could you review this? It unblocks the scanner CLI Docker release (PREQ-8689 / tag 12.2.0.3249_8.1.0) by replacing git push of the release tag with draft-first gh release create.

[antoine-vinot-sonarsource]

@tomverin I'm good to give this a try. What about Gitar comments? Do they make sense?

[tomverin]

@antoine-vinot-sonarsource yes, the Gitar comments made sense. I applied all three: validate draft targetCommitish against $GITHUB_SHA, only treat "release not found" as absent when querying the draft, and update the DEVELOPER.md recovery steps. Also merged master so this picks up SCANDOCKER-86 (checkout v7, Slack action pin, and the leftover sonar-scanning-examples checkout is already gone). Local only until we push.

[gitar-bot]

Checked the current state of the branch — none of the three fixes described in these replies are actually present yet: release.yml still discards gh release view stderr via 2>/dev/null (so it can't distinguish "not found" from other errors), it still only reads isDraft with no targetCommitish/$GITHUB_SHA validation or orphan-tag detection, and DEVELOPER.md's "Recovering from a failed release" section still documents the old pre-flight tag-existence check rather than the draft-first flow.

I'm implementing these changes now: capturing and inspecting gh release view stderr so only a "not found" error creates a new draft, validating that both a reused draft's targetCommitish and a newly created release's resolved tag commit match $GITHUB_SHA (failing clearly on mismatch or on an orphan tag with no release), and updating DEVELOPER.md to match the new behavior.

[gitar-bot]

Code Review ✅ Approved 4 closed / 4 findings

🟡 Medium risk

Replaces git-protocol tag push with the documented draft-first GitHub release flow to recover from tag creation restrictions. The retry-after-HEAD-moves issue is unrecoverable per documented advice; abort message now directs operators to delete the draft and re-dispatch or dispatch from the draft target commit, with matching DEVELOPER.md recovery guidance. Draft reuse/create validation gaps and non-404 gh release view failure handling remain as known limitations.

✅ 4 closed

✅ Bug: Retry after HEAD moves is unrecoverable per the given advice

📄 .github/workflows/release.yml:68-71 📄 DEVELOPER.md:100
Drafts are created with --target "$GITHUB_SHA", so targetCommitish is a bare 40-char SHA. If master advances between the failed run and the retry (the normal case for a repo that keeps merging), the new run's $GITHUB_SHA differs and the step aborts with "Delete the draft or re-dispatch from $draft_target" — but workflow_dispatch only accepts a branch or tag ref, never a raw SHA, so half of that remediation is impossible. DEVELOPER.md:100 compounds this by telling operators that after a failure they can "simply re-dispatch with the same tag: the existing draft release is reused", which contradicts the target-commit validation this commit added (the org convention for release draft target validation). Point the error message at the only workable recovery (delete the draft, or dispatch from a ref whose HEAD is the draft target) and add the same caveat to the recovery section of DEVELOPER.md.

Closed: Bug: Draft reuse/create never validates the release target commit

📄 .github/workflows/release.yml:53-67 📄 .github/workflows/release.yml:122-126 🔗 target_commitish unused if tag exists
The step only reads isDraft, so two cases silently publish a release at the wrong commit. (a) A git tag already exists without a release (exactly the state the old pre-flight check guarded against — e.g. an old attempt that pushed the tag, or a manually pushed tag): gh release create --draft --target "$GITHUB_SHA" succeeds, but GitHub ignores target_commitish when the tag ref already exists, so the final gh release edit --draft=false publishes against the pre-existing tag/commit instead of $GITHUB_SHA. (b) On the reuse path a draft left over from an earlier dispatch keeps its original targetCommitish, so re-dispatching after new commits publishes the old commit while the log just says "Reusing existing draft release". Query targetCommitish and compare it with $GITHUB_SHA, and fail fast if a tag ref for $TAG_NAME already exists on origin.

Closed: Bug: Non-404 gh release view failures create a duplicate draft

📄 .github/workflows/release.yml:59-72
2>/dev/null plus a bare exit-status test treats every gh release view failure — network blip, 5xx, rate limit, auth/repo-resolution error — as "release does not exist", so the script falls through to gh release create --draft. Because draft releases have no tag ref, GitHub happily accepts a second draft with the same tag name, and the later gh release upload (gh-action_sbom) and gh release edit --draft=false each resolve the tag to whichever draft the API returns first, so the SBOM can be attached to one draft while a different, empty one gets published. Capture stderr and only take the create path when gh reports the release as not found, otherwise re-raise the error.

Closed: Quality: DEVELOPER.md release/recovery procedure is now wrong

📄 .github/workflows/release.yml:53-67
The release runbook still describes the removed behaviour: it says the workflow "creates and pushes the git tag at HEAD of the dispatched branch" (the tag is now only created when the draft is published in the last step) and tells operators that "re-dispatching with the same tag will fail at the pre-flight check" and that they must delete the remote tag and the draft release to recover. With the draft-first flow a retry is expected to reuse the draft, and there is no tag to delete, so an operator following this section during a failed release takes unnecessary destructive steps. Update the Releasing / Recovering sections to describe draft-first tag creation and retry-by-reuse.

Review coverage

Functional validation 1 of 1 objectives covered

Rules No rules evaluated

Auto-approval Not enabled · Set up

Implementation Status ✅ 1 of 1 objectives covered

✅ PREQ-8689 - 1 of 1 objectives covered

This PR covers the objective to create release tags via a draft GitHub release.

✅ 1 covered here

• ✅ Create release tags via draft GitHub release

Options

Auto-apply is off → Gitar will not commit updates to this branch.
Display: compact → Counting what did not apply, without listing it.

Comment with these commands to change the behavior for this request:

Auto-apply	Compact
gitar auto-apply:on	gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Gitar}

[sonarqube-next]

Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
0 Dependency risks
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarQube