Conversation
The release process docs told maintainers to create release tags with `git tag -a`, which produces an annotated but unsigned tag. That has not matched actual practice for some time: every release tag from 6.0.0rc3 onward is GPG signed, and the devcontainer deliberately sets both COMMIT_GPGSIGN and TAG_GPGSIGN so that tags created inside it are signed by default. The docs simply never caught up. Switch both tag commands to `git tag -s`, add a "Tag Signing" subsection stating the requirement once ahead of both commands, and note that `commit.gpgsign` does not sign tags, so signed tags need `tag.gpgsign` or an explicit `-s`. That last point is the root cause of the drift and is not obvious outside the devcontainer. Co-Authored-By: Claude Opus 5 <[email protected]>
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #283 +/- ##
=======================================
Coverage 94.49% 94.49%
=======================================
Files 49 49
Lines 4163 4163
=======================================
Hits 3934 3934
Misses 229 229 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Contributor
There was a problem hiding this comment.
🟢 Approval recommended
The focused documentation changes have no unresolved issues.
Pull request overview
This PR updates release documentation to require signed annotated tags.
Changes:
- Replaces
git tag -awithgit tag -s. - Adds tag-signing guidance and configuration notes.
- Clarifies signing in the release checklist.
File summaries
| File | Summary |
|---|---|
docs/source/developers.md |
Documents and applies signed release-tag usage. |
Review details
- Files reviewed: 1/1 changed files
- Comments generated: 0
- Review effort level: Lite
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
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
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
Addresses issue #279.
docs/source/developers.mddocumentedgit tag -afor release tags, which creates an annotated but unsigned tag. That has not matched actual practice for some time. This PR brings the docs in line with the convention.Changes, all confined to
docs/source/developers.md:git tag -sinstead ofgit tag -a.#### Tag Signingsubsection under "Automatic Release Process", placed ahead of both tag code blocks so the rule is stated once.commit.gpgsigndoes not sign tags: signed tags need eithertag.gpgsign = trueor an explicit-son each invocation. This is the actual root cause of the drift and is non-obvious to anyone working outside the devcontainer.Not changed: the sentence at line 52 saying the workflow "responds to pushes of annotated git tags".
.github/workflows/release.ymltriggers on the tag name pattern only and does not verify a signature, so calling it "signed" there would describe enforcement that does not exist.Why "must" rather than "preferred" — review question
The wording asserts that release tags must be signed. Evidence:
.devcontainer/devcontainer.jsonsets bothCOMMIT_GPGSIGN=trueandTAG_GPGSIGN=trueinremoteEnv, and.devcontainer/setup-dev-environment.shapplies both as git config and errors/warns if signing was requested but is unavailable. Tag signing is deliberate configuration, not incidental.6.0.0rc3onward is signed (verified against the tag objects):6.0.0rc3,6.0.0rc4,6.0.0,6.0.1,6.1.0,6.1.1,6.1.2,6.2.0."Preferred" would leave the next maintainer free to use
-a, which is the exact failure this fixes. That said, this is a policy call that is yours to make — if you would rather the docs say "should" or "preferred", it is a one-word change and I am happy to soften it.Out of scope
This PR intentionally does not touch
.claude/skills/cut-a-release/SKILL.md, because that file does not exist onmainyet — it is added by unmerged PR #278. Its Step 7 "Deliberate deviation fromdevelopers.md" callout (and the "The single exception is flagged inline in Step 7" sentence in its preamble) become redundant once this lands, and should be removed in a follow-up after #278 merges; issue #279 should stay open until that cleanup is done. That is why this PR links the issue without a closing keyword.CHANGELOG
No CHANGELOG entry was added, and I believe none is necessary. The precedent splits on audience: developer-process documentation changes have not gotten entries, while user-facing documentation changes have. #222 ("Update release process docs") and #240 ("Update developer setup documentation") both touched
developers.mdonly and added no entry; #273 (reorganize user documentation) did add one. This PR is squarely in the first category.Verification
grep -n "tag -a" docs/source/developers.mdreturns nothing.pre-commit run --all-filespasses, including prettier, with no rewrites.uv sync --all-extras && cd docs && make html);docs/build/html/developers.htmlrenders the callout as<div class="admonition note">, not literal text. The note uses a fenced MyST{note}directive rather than a GitHub-style> [!NOTE], since 6.2.0 shipped a fix for exactly that rendering bug.git diff --stat mainshows onlydocs/source/developers.md(16 insertions, 3 deletions).🤖 Generated with Claude Code