docs(agents): correct release flow — auto-tag, not manual#93
Conversation
CI's gh release create handles tag creation on merge; humans don't push tags. Old wording implied a manual tag step that hasn't matched reality since v3.3.1. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
Important Review skippedReview was skipped due to path filters ⛔ Files ignored due to path filters (1)
CodeRabbit blocks several paths by default. You can override this behavior by explicitly including those paths in the path filters. For example, including ⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Comment |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request updates the AGENTS.md documentation to reflect the automated release flow, specifically detailing how the publish workflow handles versioning and tagging. Feedback was provided to clarify the instructions for manual version bumps to ensure the workflow correctly honors manually pushed tags.
| - `deploy` job pushes packages to NuGet via trusted publishing, then `gh release create v$VERSION` creates the GitHub release **and the tag** in one step | ||
| 3. NuGet indexes in ~4-8 minutes — downstream repos pick up via Renovate | ||
|
|
||
| Manual `git tag vX.Y.Z` on `main` is **not** part of the flow — the workflow owns version computation and tag creation. To force a minor/major bump instead of the auto-patch, push a tag manually before the workflow runs (compute_version honors the existing tag on HEAD). |
There was a problem hiding this comment.
The instruction to "push a tag manually before the workflow runs" is ambiguous because the workflow triggers immediately upon merge. It is clearer to specify that the tag should be pushed to the commit on main to ensure the version computation logic honors it. Additionally, if the workflow has already started, it may need to be re-run to pick up the manual tag.
| Manual `git tag vX.Y.Z` on `main` is **not** part of the flow — the workflow owns version computation and tag creation. To force a minor/major bump instead of the auto-patch, push a tag manually before the workflow runs (compute_version honors the existing tag on HEAD). | |
| Manual git tag vX.Y.Z on main is not part of the standard flow — the workflow owns version computation and tag creation. To force a minor/major bump instead of the auto-patch, push the desired tag to the commit on main (the compute_version step honors an existing tag on HEAD). |
![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: 9d8a790d03
ℹ️ 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".
|
|
||
| ### Release flow | ||
|
|
||
| Tagging is automated, not manual: |
There was a problem hiding this comment.
This new section says releases are triggered automatically on merges to main, but the earlier “Cross-Repo Awareness” bullet still states that publish triggers on v* tag pushes (AGENTS.md line 203). Keeping both instructions in the same file makes the operational runbook ambiguous and can lead maintainers to follow the wrong release path. Please update the older bullet so the document has one consistent trigger model.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Pull request overview
Updates the ANcpLua.Agents release documentation to reflect the repository’s current automated tagging and publishing behavior driven by the publish GitHub Actions workflow.
Changes:
- Replaces the old “manual tag on main” step with the actual on-merge auto-versioning + auto-tagging flow.
- Documents
compute_versionpatch auto-bump behavior and theMust Publish Packagespath gate. - Notes that
gh release createcreates both the GitHub release and the tag during deploy.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| - `deploy` job pushes packages to NuGet via trusted publishing, then `gh release create v$VERSION` creates the GitHub release **and the tag** in one step | ||
| 3. NuGet indexes in ~4-8 minutes — downstream repos pick up via Renovate | ||
|
|
||
| Manual `git tag vX.Y.Z` on `main` is **not** part of the flow — the workflow owns version computation and tag creation. To force a minor/major bump instead of the auto-patch, push a tag manually before the workflow runs (compute_version honors the existing tag on HEAD). |
Previous wording implied the SDK's auto-tag-on-merge applies ecosystem-wide. It doesn't: - Sdk: auto-bump-on-merge, workflow creates tag + release - Roslyn.Utilities, Agents: manual tag push triggers publish + release - Analyzers: manual tag push triggers publish only (no GH release) Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Summary
compute_versionauto-bumps patch from latestv*tagMust Publish Packagesgate checks*.nuspec,src/**/*,tests/**/*gh release create v$VERSIONcreates the GitHub release and the tag in one stepTest plan
src/**change)🤖 Generated with Claude Code