ci(release-please): promote graduated releases to GitHub full release

[devin-ai-integration]

Summary

Make graduated strict-D releases (e.g. v0.3.0) appear as full releases in the GitHub UI — and, iff they're the highest stable semver, as the repo's "Latest release" — instead of being flagged as pre-releases.

Why this exists

release-please-config.json sets repo-level "prerelease": true because rc tags (v0.3.0-rc1) should be marked pre-release on GitHub. The flag is uniform across all releases release-please creates, though, so graduated stable tags (v0.3.0) also end up pre-release in the UI — even though the OCI publish side correctly pushes :0.3.0, :stable, :latest (that path reads git tags, not GitHub release metadata).

What this PR changes

Adds a new step to release-please.yaml's dispatch-publish job, running after the workflow_dispatch against the new tag. For each tag release-please creates:

• If the tag has a prerelease suffix (contains -, e.g. v0.3.0-rc1) → leave GitHub release flags untouched (remains pre-release).
• If the tag is a clean stable (no - in the version, e.g. v0.3.0) → gh release edit to flip prerelease=false, and set latest=true|false based on whether this is the highest stable semver.

Highest-stable detection mirrors ci.yaml's versions job exactly:

git tag -l 'v[0-9]*.[0-9]*.[0-9]*' | grep -v -- '-' | sort -V | tail -n1

This keeps the GitHub release's "Latest" flag in lockstep with the OCI :latest pointer on image + chart (same tag glob, same - filter, same semver sort). Correctly handles backports — e.g. releasing v1.1.9 after v1.2.0 exists would mark the 1.1.9 release as a full release but NOT as "Latest", matching the moving-tag policy for the chart/image.

The new step also gets fetch-depth: 0 on the existing checkout so git tag -l sees the full tag list.

Backfill for the existing v0.3.0 release

Done manually via gh release edit v0.3.0 --prerelease=false --latest=true. Confirmed via the API:

$ gh api /repos/bcit-tlu/haproxy-operator/releases/latest --jq '{tag_name, name, prerelease}'
{"name":"v0.3.0","prerelease":false,"tag_name":"v0.3.0"}

So v0.3.0 is now the correct "Latest release" on the releases page. Future graduated releases will land that way automatically without the manual backfill.

Review & Testing Checklist for Human

• Sanity-check the bash logic in the new step — especially the VERSION == HIGHEST_STABLE comparison for backport cases (e.g., imagine v1.1.9 released after v1.2.0 is out; the step should call --latest=false).
• Confirm the dispatch-publish job's fetch-depth: 0 bump is acceptable (tiny extra checkout cost; required so git tag -l sees all tags).
• The real end-to-end test will happen on the next graduated release. When you cut v0.3.1 (or whatever the next stable is), verify it shows up as "Latest release" on the releases page and not as Pre-release.

Notes

• No change to release-please-config.json — repo-level "prerelease": true stays because rc releases do need to be flagged pre-release.
• GitHub's release-edit flag --latest permits explicit opt-out of auto-detection; passing --latest=false prevents accidentally bumping "Latest" on backport releases.
• The new step only runs when releases_created == true (job-level if: already gates this); safe no-op otherwise.

Link to Devin session: https://app.devin.ai/sessions/8688f4d14a8f46839fd8ede494e61166
Requested by: @kphunter

---

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

⚙️ Control Options:

• Disable automatic comment and CI monitoring

[devin-ai-integration]

✅ Devin Review: No Issues Found

Devin Review analyzed this PR and found no potential bugs to report.

View in Devin Review to see 2 additional findings.