Repository navigation
docs: document release/tagging convention - #27
Conversation
Releases were cut ad hoc by tagging merge commits directly, with no documented convention. Record the manual flow and the chore: release x.y.z commit expectation so future releases are consistent.
|
Claude finished @mashkovd's task in 27s —— View job Release Documentation Review✅ No P1/P2 findings, good to merge. This is a straightforward documentation addition to CLAUDE.md that clearly documents the existing manual release process:
The documentation is clear, follows the existing style of CLAUDE.md, and addresses the audit finding about missing release conventions. No issues identified. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: dedcb5e5ff
ℹ️ 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".
| - Semantic version tags, NO `v` prefix (e.g. `1.9.0`). Pushing a matching tag | ||
| triggers `.github/workflows/build.yml`, which builds/pushes the image and bumps | ||
| the gitops manifest. |
There was a problem hiding this comment.
This new no-v release convention leaves the existing README release process contradicting it: README still tells users to run git tag v1.2.3, while the workflow trigger I checked in .github/workflows/build.yml starts with a numeric character class ([0-9]*.[0-9]*.[0-9]*) and therefore won't run for v... tags. Anyone following the public README after this change can still create a tag that skips the release build/GitOps bump, so please update the README release section or make one canonical doc authoritative in the same change.
Useful? React with 👍 / 👎.
Adds a Releases section to
CLAUDE.mddocumenting how mctl-agent cuts releases.Context: the mctlhq best-practices audit (item 3) flagged that no
chore: release x.y.zcommits exist across 30+ tags. mctl-agent has no release-please automation — tags are pushed manually onto feature-PR merge commits, which triggersbuild.yml.This is the trivial, low-risk fix: document the existing manual flow plus the org's
chore: release x.y.zcommit convention so future releases are consistent. Full release-please onboarding (as used by mctl-portal) is a larger opt-in decision left to the user.