chore(release): graduate haproxy-operator to 0.3.0 - #12
Merged
Conversation
Force release-please to cut a clean-stable 0.3.0 release (no -rc suffix) on the next release PR it opens. Adds 'release-as: 0.3.0' + 'prerelease: false' per-package overrides so the prerelease-type rc logic does not re-append '-rc' to the pinned version. After the release-please PR that uses this override merges and the v0.3.0 tag is created, a follow-up PR will remove these overrides so normal rc-based bumping resumes for the next cycle. Co-Authored-By: kyle_hunter@bcit.ca <kyle_hunter@bcit.ca>
Contributor
Author
🤖 Devin AI EngineerI'll be helping with this pull request! Here's what you should know: ✅ I will automatically:
⚙️ Control Options:
|
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
3 tasks
kphunter
added a commit
that referenced
this pull request
Apr 21, 2026
) Follow-up to #12 / #9. Two related cleanups: 1. Remove the temporary graduation overrides that forced release-please to cut a clean '0.3.0' instead of '0.3.0-rc': - 'release-as': '0.3.0' - 'prerelease': false With '0.3.0' now on main, leaving these in would make release-please keep proposing 0.3.0 on every run (no-op but noisy) and block the next normal rc bump. 2. Remove the vestigial 'component': 'haproxy-operator' entry. Under strict-D this repo uses 'include-component-in-tag': false, so tags are 'vX.Y.Z' (no component prefix). The component field was a holdover from pre-strict-D (when the tag was 'haproxy-operator-v*'). With 'separate-pull-requests': false + no custom title pattern, release-please renders the release PR title as 'chore: release main' — which contains no ${component} token. On the post-merge run of PR #9 this caused release-please to log 'PR component: undefined does not match configured component: haproxy-operator' while building the release for path '.', and abort without creating the v0.3.0 tag or GitHub release. The follow-up 'dispatch-publish' step was therefore skipped, so the 0.3.0 image/chart were never published and the moving 'stable'/'latest' OCI pointers were not moved. Dropping the single-package component brings the config in line with a normal single-component strict-D repo (compare tech-ops-docs) and lets release-please parse 'chore: release main' correctly on future releases. Co-authored-by: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> Co-authored-by: kyle_hunter@bcit.ca <kyle_hunter@bcit.ca>
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
1 participant
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
Instructs release-please to cut a clean-stable
0.3.0release (no-rcsuffix) on its next run.Two per-package overrides added to
release-please-config.json:release-as: "0.3.0": pins the next version explicitly. Minor bump from0.2.0becausefeat:commits (scaffold, strict-D CI adoption) have landed since the last release.prerelease: false: overrides the repo-levelprerelease: truesoprerelease-type: "rc"does not re-append-rcon top of the pinned version.Flow after this merges:
0.3.0-rc) will be rewritten on the next run to propose0.3.0(no-rc).v0.3.0tag and GitHub Release.release-please.yamlre-dispatchesci.yamlagainstrefs/tags/v0.3.0(viagh workflow run --ref <tag>); the re-dispatch publishes the immutable0.3.0image+chart plus movesstable+latestOCI pointers (this will be the highest-stable SemVer for the repo).ref.tag: stable) picks up the new revision automatically — once flux-fleet'sapps/haproxy-operator/base/ocirepository.yamlis flipped fromref.tag: latestto the proper stable/head pattern (separate follow-up).Follow-up required: once the
v0.3.0tag is cut and artifacts published, open a second PR that removes therelease-as+prerelease: falseoverrides. Without the removal, release-please will keep proposing0.3.0on every run (no-op after the tag exists, but noisy) and block the next normal rc bump.Review & Testing Checklist for Human
0.3.0matches your intent (the open release-please PR currently proposes0.3.0-rc; this forces graduation directly to stable without cutting the rc first).0.3.0(no-rcsuffix).ghcr.io/bcit-tlu/haproxy-operator/haproxy-operator:0.3.0and:stable+:latestpointers moved to that digest. Same for the chart:.../charts/haproxy-operator:0.3.0+:stable+:latest.release-asoverrides.Notes
Skipping the rc step is intentional here — the alternative (merge #9 to cut
v0.3.0-rc, wait for bake-time, then file another Release-As forv0.3.0) adds an extra publish+tag cycle without meaningful signal at this stage of adoption. If you'd prefer the two-step path (rc → full) for more conservative rollout, close this PR and merge #9 instead.Link to Devin session: https://app.devin.ai/sessions/a5e23b4cc3a34f4caa54267af3c1ccc4
Requested by: @kphunter