feat: add stable promotion workflow

[randy-concepcion]

What's New

• Adds .github/workflows/promote-release.yml, triggered on release: released. Promotes an RC-tagged image to its stable tag in GAR by tagging the existing digest, no rebuild.
• Removes the release: published trigger from docker-publish.yml, which rebuilt the image and produced a different digest than the main-push build. The vX.Y.Z tag is now created by promote-release.yml instead.
• Removes [skip ci] from the auto-bump commit message so bump commits get a main-push build and land a short-SHA image in GAR. The auto-bump job won't loop, since it exits when project.version is already ahead of the latest tag.

Context

Part of AIPLAT-911. Together with #212 this provides the RC-tagging and stable-promotion mechanics for MLPA, so a released image carries its short-SHA, RC, and stable tags on the same digest instead of being rebuilt at release time.

flowchart LR
    A[merge to main] --> B["build<br/>(short-SHA tag)"]
    B --> C["RC workflow #212<br/>adds vX.Y.Z-rc.N"]
    C --> D["validate RC on stage<br/>(manual)"]
    D --> E["create GitHub release<br/>(manual)"]
    E --> F["this PR<br/>adds vX.Y.Z"]

    style F fill:#e8f4f8

Loading

Testing

Cannot be tested end to end before merge. The workflow only triggers on release: released, so it can't be run from a PR branch.

It also can't be validated against past releases. Previous bump commits never got a main-push build, so their short-SHA images aren't in GAR. A run against v1.0.22 or earlier fails with "Source image ... could not be resolved." That's expected.

Validation on the first release after this merges:

1. Confirm the next auto-bump commit produces a short-SHA image in GAR
2. Run the RC tagging workflow against that commit
3. Create the GitHub release
4. Confirm the stable tag, RC tag, and short-SHA tag all resolve to the same digest

Notes

• Promotion is safe to rerun. An existing stable tag on the expected digest succeeds; the same tag on a different digest fails rather than repointing.
• latest is untouched and stays owned by the main-push build. A release can target a commit behind main, so moving latest at release time could roll dev backward.
• Promotion creates the stable tag but deploys nothing. Prod moves through the usual values-prod.yaml change and Argo sync.
• Bump commits now run full CI on their main push, which is the tradeoff for giving the release commit a promotable image.
• Shares registry logic with feat: add release candidate tagging workflow #212. Keeping it inline for now. We can revisit a shared helper if a third caller shows up.

Related

• AIPLAT-911
• Depends on feat: add release candidate tagging workflow #212, merge that first. A release cut before it exists would have no RC tag to gate on.

[noahpodgurski]

This is a great addition, we've accidentally released tags without the v-prefixed version before 🙌