Skip to content

chore: release main - #9

Merged
kphunter merged 2 commits into
mainfrom
release-please--branches--main
Apr 21, 2026
Merged

chore: release main#9
kphunter merged 2 commits into
mainfrom
release-please--branches--main

Conversation

@github-actions

@github-actions github-actions Bot commented Apr 19, 2026

Copy link
Copy Markdown

🤖 I have created a release beep boop

0.3.0

0.3.0 (2026-04-21)

Features

  • ci: unify image, chart, and release versions under release-please lineage (#10) (db7fcb5)
  • scaffold haproxy-operator with Flux GitOps, SPIRE mTLS, and VSO integration (7e80e93)

Bug Fixes

  • address Devin Review findings — SPIRE lifecycle, double validation, dynamic RootCAs, unit tests (4985dc0)
  • ci: unblock image job on private-repo SARIF upload (#11) (8e40960)
  • clear LastFailedHashAnnotation on successful apply (0616620)
  • retry client init on failure, context-aware waitForReady, deduplicate events (f66f835)
  • SPIRE source leak on client error, atomic file watch, example config indent (ac48a4f)
  • store status-message in annotations, skip failed-hash retry loop, add tests (4a23d60)
  • use modern httpchk syntax for HAProxy 2.2+ in dev examples (5954e82)

This PR was generated with Release Please. See documentation.


Open in Devin Review

@github-actions
github-actions Bot force-pushed the release-please--branches--main branch 2 times, most recently from 3712ebb to 18f3758 Compare April 21, 2026 01:59
@github-actions
github-actions Bot force-pushed the release-please--branches--main branch from 18f3758 to 854d5f7 Compare April 21, 2026 02:22
devin-ai-integration[bot]

This comment was marked as resolved.

release-please's default updater for Chart.yaml only bumps 'version:' and
strips inline YAML comments (including the 'x-release-please-version'
markers), leaving appVersion frozen at the previous release and deleting
the markers the next release-please run needs to locate the lines.

- Restore appVersion to 0.3.0 so the committed chart matches the release
  (CI's sed commands in .github/workflows/ci.yaml also stamp the same
  value at publish time, but the committed Chart.yaml is what helm
  install uses from the repo source).
- Restore both 'x-release-please-version' markers and the explanatory
  comment block.
- Pin the extra-files entry for Chart.yaml to the 'generic' updater so
  future release-please runs preserve the markers and update both
  'version' and 'appVersion' in lockstep.

Co-Authored-By: kyle_hunter@bcit.ca <kyle_hunter@bcit.ca>
@devin-ai-integration

Copy link
Copy Markdown
Contributor

Took over to address both Devin Review findings on charts/haproxy-operator/Chart.yaml.

Root cause: release-please's default auto-detected updater for Chart.yaml (the Helm updater) only bumps the version: line and strips inline YAML comments — including both x-release-please-version markers. That is why appVersion stayed at 0.2.0 and the markers disappeared despite extra-files listing the file.

Fixes in 00c8741:

  1. charts/haproxy-operator/Chart.yaml — restored appVersion: "0.3.0", re-added both x-release-please-version markers, and restored the lockstep comment block.
  2. release-please-config.json — changed the extra-files entry for Chart.yaml from the auto-detected short-string form to explicit object form with "type": "generic". The generic updater targets lines by their marker comment and preserves them, so future release-please runs will bump both version and appVersion in lockstep without stripping the markers.

CI's sed stamps in .github/workflows/ci.yaml:341-342 still act as a belt-and-suspenders at publish time, but the committed Chart.yaml is now correct on its own (matters for anyone running helm install from the repo source or reading chart metadata in git).

devin-ai-integration[bot]

This comment was marked as resolved.

@kphunter
kphunter merged commit a1d1058 into main Apr 21, 2026
6 checks passed
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>
@github-actions

Copy link
Copy Markdown
Author

🤖 Created releases:

🌻

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant