chore(main): release 3.1.1#175
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 2bfafab1b1
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| version: 3.1.1 | ||
| appVersion: 3.1.0 |
There was a problem hiding this comment.
Keep chart appVersion in sync with release version
This release bumps version to 3.1.1 but leaves appVersion at 3.1.0, so the published Helm metadata will report the previous app release for this chart version. That mismatch can mislead chart consumers and release tooling that rely on appVersion to identify what application build a chart contains; this release should update appVersion to the new version as part of the release PR.
Useful? React with 👍 / 👎.
The canonical `chore${scope}: release${component} ${version}` pattern
trips release-please v4's own "miss the part of '${scope}'" warnings
and falls back to `chore: release ${branch}` — which leaves the merged
PR title with no version, breaking the post-merge component match and
blocking tag creation.
Use the simpler `chore(main): release ${version}` pattern that actually
produced working titles in #175 / #177 (e.g. `chore(main): release 3.1.1`).
…#188) * fix(ci): restore release-please pull-request-title-pattern Without an explicit title pattern, release-please v4 generates "chore: release main" and the PR title carries no ${component}. When the PR is merged, createReleases then fails its post-merge match check: ⚠ PR component: undefined does not match configured component: gateway so the tag + GitHub release are never cut. The candidate-PR phase then aborts with "There are untagged, merged release PRs outstanding", blocking every subsequent release until the label is manually fixed. That regression was introduced in #179 (dropped the pattern added in #178). v3.3.0 and v3.4.0 both required a manual recovery (tag + release + relabel + workflow_dispatch publish). Restore the canonical pattern so release-please produces titles like "chore(main): release 3.4.1" which it can parse back after merge. * fix(ci): use simpler release-please title pattern that actually works The canonical `chore${scope}: release${component} ${version}` pattern trips release-please v4's own "miss the part of '${scope}'" warnings and falls back to `chore: release ${branch}` — which leaves the merged PR title with no version, breaking the post-merge component match and blocking tag creation. Use the simpler `chore(main): release ${version}` pattern that actually produced working titles in #175 / #177 (e.g. `chore(main): release 3.1.1`).
🤖 I have created a release beep boop
3.1.1
3.1.1 (2026-04-11)
Bug Fixes
This PR was generated with Release Please. See documentation.