BUILD-11107 Switch release workflow to workflow_dispatch

[julien-carsique-sonarsource]

Summary

• Replace release:published event trigger with workflow_dispatch so the SBOM is generated and attached before the release is published, avoiding GitHub Release Immutability restrictions
• The workflow now creates the git tag at HEAD from the provided tag_name input
• Pass release-tag to SonarSource/gh-action_sbom so it can attach assets to a draft release even when GITHUB_REF is a branch ref
• The release is published at the end of the workflow via gh release edit --draft=false
• Pin actions/checkout references by commit SHA

Release flow

workflow_dispatch(tag_name) 
  → validate version format
  → create git tag at HEAD
  → gh-action_sbom auto-creates draft release, attaches SBOM
  → promote + push to Docker Hub
  → gh release edit --draft=false  (publish)

References

• https://sonarsource.atlassian.net/browse/BUILD-11107
• Depends on BUILD-11107 Support GitHub Release Immutability gh-action_sbom#80

Test plan

• Dispatch the workflow with a valid tag name — verify the tag is created, SBOM is attached to the draft release, and the release is published at the end
• Dispatch with an invalid tag format — verify early exit with a clear error message

[hashicorp-vault-sonar-prod]

BUILD-11107

[sonar-review-alpha]

Summary

This PR switches the release workflow from being triggered by release:published events to manual dispatch via workflow_dispatch, solving GitHub's immutability restrictions that prevent attaching SBOM assets after a release is published.

The workflow now:

1. Creates the git tag itself at HEAD (new step)
2. Allows the SBOM action to attach assets to a draft release (via new release-tag input)
3. Publishes the release at the end (new step), after all assets are attached

Also includes minor fixes: regex validation corrected to allow single-digit major versions and literal dots; actions/checkout pinned by commit SHA for security.

What reviewers should know

Start here: Review the trigger change (line 3-10) and the new "Create and push release tag" step (lines 52-65) to understand the sequence change.

Key decision: The ref parameter was removed from the first checkout (line 48) because the tag doesn't exist yet—it's created by the workflow itself. The second checkout (examples repo) is unaffected.

Critical new inputs:

• tag_name is now a required workflow input (replaces github.event.release.tag_name)
• release-tag parameter added to gh-action_sbom action (line 77) — this depends on SonarSource/gh-action_sbom#80 being merged
• Tag creation includes conflict detection with helpful error instructions

Security: actions/checkout references pinned by commit SHA (ee0669bd1cc54295c223e0bb666b733df41de1c5 for v2).

Validation to verify: Regex pattern now correctly validates format {major}.{minor}.{patch}.{build}_{scanner_major}.{scanner_minor}.{scanner_patch} with literal dots (escaped) and allows single-digit majors (changed [1-9][0-9]+ to [1-9][0-9]*).

Slack notifications updated to use inputs.tag_name instead of the release event data—confirm notifications still fire correctly on success/failure.

---

• Generate Walkthrough
• Generate Diagram

🗣️ Give feedback

[sonar-review-alpha]

LGTM! ✅

All three previously flagged issues have been addressed correctly in this iteration:

• Regex fix (line 37): [1-9][0-9]* now allows single-digit major versions; . separators properly escaped as \..
• Tag existence check (lines 57–62): The pre-flight guard prevents duplicate tag creation and gives actionable cleanup instructions covering both the git tag and any orphaned draft release.

permissions: contents: write (line 16) is already present in the unchanged part of the file, so both git push origin "$TAG_NAME" and gh release edit --draft=false will have the necessary token scope. No new issues found.

🗣️ Give feedback

[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

[matemoln]

What do you think about adding a section to the DEVELOPER.md on creating a release on a long-lived branch? In this case the release workflow must be run from the branch-* branch and not from master, right?