release: switch workflow to annotated tags + add RELEASING.md#108
Open
jamesbroadhead wants to merge 1 commit into
Open
release: switch workflow to annotated tags + add RELEASING.md#108jamesbroadhead wants to merge 1 commit into
jamesbroadhead wants to merge 1 commit into
Conversation
jamesbroadhead
requested review from
a team,
lennartkats-db and
simonfaltum
as code owners
The release workflow used `gh release create "$VERSION"` which creates a **lightweight** tag (objecttype=commit). `git tag -v` cannot verify lightweight tags — they have no tag object to attach a signature to. v0.1.0 through v0.2.1 are all lightweight, so the README "Integrity" claim that future tags are GPG-signed and verifiable couldn't be honoured even if signing were turned on. Changes: - `.github/workflows/release.yml`: create an annotated tag with `git tag -a` and push it, then `gh release create --verify-tag` to ensure the tag exists before the release. - `README.md` Integrity section: stop claiming "future tags will be GPG-signed" as a present fact; describe the actual state (annotated now, signed pending GPG/Sigstore enablement) and link to RELEASING.md. - `RELEASING.md`: new doc covering the release procedure, `git tag -v` verification flow, and the path forward to actual signing (GPG via secrets vs Sigstore/gitsign via OIDC). Signing itself is intentionally left for a follow-up — it requires either a release-identity GPG key + GH Actions secret or a Sigstore runtime in the workflow, and the choice between those is a team decision. Annotated tags are the strict prerequisite, and this PR unblocks that. This PR was prepared by Claude.
jamesbroadhead
force-pushed
the
jb/release-annotated-tags
branch
from
ce898ab to
9cd8a33
Compare
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
1 participant
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
The release workflow used
gh release create "$VERSION"which creates a lightweight tag (objecttype=commit).git tag -vcannot verify lightweight tags — they have no tag object to attach a signature to.v0.1.0throughv0.2.1are all lightweight, so the README "Integrity" claim that future tags are GPG-signed and verifiable couldn't be honoured even if signing were turned on.This PR makes annotated tags the default in the release workflow — the strict prerequisite for
git tag -vand for GPG/Sigstore signing.Changes
.github/workflows/release.yml— split tag creation from release creation.git tag -a "$VERSION" -m "$VERSION", push the tag, thengh release create --verify-tag(confirms the tag exists before the release).README.mdIntegrity — stop claiming "future tags will be GPG-signed" as a present fact; describe the actual state (annotated now, signed pending GPG/Sigstore enablement) and link to RELEASING.md.RELEASING.md— new doc covering the release procedure,git tag -vverification, and the signing follow-up.Out of scope (follow-up)
Signing itself. It requires either:
git tag -s.sigstore/gitsignin the workflow; no long-lived secret; OIDC token is the identity.Either approach satisfies the README claim. The choice is a team decision; annotated tags are the strict prerequisite that this PR unblocks.
Existing
v0.1.x/v0.2.xtags stay lightweight (would need re-tagging to convert) — RELEASING.md covers both options for that question.Test plan
python3 scripts/skills.py validatepasses (no skill content touched).v0.0.0-rc1) in a follow-up to confirm annotated-tag creation works on the protected runner.This pull request and its description were written by Claude.