fix(ci): fetch-tags on tag-introspection checkouts so signed annotated tags pass

[branarakic]

Summary

The release.yml Validate release candidate job and the npm-publish.yml Require signed annotated tag job both rely on git cat-file -t <tag> returning tag for annotated tags. They use actions/checkout@v4 to materialise the tag, but without fetch-tags: true — which means the runner gets a synthetic lightweight ref pointing at the commit, not the tag-object.

So git cat-file -t v10.0.0-rc.8 returns commit instead of tag, and the structural signed-tag gate rejects the (correctly signed) tag with:

Tag v10.0.0-rc.8 is a lightweight ref (git object type \`commit\`), not an annotated tag.
Lightweight tags cannot carry a signature.

This was the failure mode on the v10.0.0-rc.8 push earlier today (release.yml run 25943282274). The tag was correctly created with git tag -s — git ls-remote shows it as a tag object whose ^{} peels to the merge commit on main, and the body contains the expected -----BEGIN SSH SIGNATURE----- block.

Author intent is unambiguous

From release.yml lines 100–124:

LAYER 1 (HARD GATE) — structural signed-tag detection. […] We CAN reliably detect whether the tag is signed AT ALL: a signed annotated tag's object body always contains a PGP/SSH signature block. An unannotated ("lightweight") tag has no object body — it is just a ref to a commit. Either case is rejected here.

The gate is supposed to PASS legitimately-signed annotated tags. The bug is purely the missing fetch-tags: true.

Change

14 lines, in two places:

• release.yml Validate release candidate checkout (line 53–60)
• npm-publish.yml Require signed annotated tag checkout (line 226–230)

Both gain fetch-tags: true plus a 6-line comment explaining why the option matters.

No version bump (workflow-only change). No test changes (these are CI gates that fire only on tag pushes).

Other checkouts in these workflows

Audited:

• release.yml line 281 (Build MarkItDown binary): doesn't read tag annotation, no change needed.
• release.yml line 428 (Build, test, and create release): uses --notes-file release_notes.md (sourced from CHANGELOG.md), not the tag annotation; doesn't need fetch-tags.
• npm-publish.yml line 284 (build-and-pack): only reads .nvmrc and package.json; doesn't need fetch-tags.

So the minimal correct fix is exactly these two checkouts.

Test plan

• Diff is workflow-only (.github/workflows/)
• No package.json versions touched
• Audited every other actions/checkout in both workflows for the same bug
• CI passes on this PR (no tag pushes triggered, so the relevant gates won't fire here — they fire on the next tag push)
• After merge: delete v10.0.0-rc.8 (local + remote), re-tag against new main HEAD, push → release.yml passes structural gate → reviewer approves npm-publish Environment → publish completes

Why this didn't fire before

v10.0.0-rc.7 and earlier went through the OLD continuous-publish-on-merge flow. PR #522 introduced the new tag-triggered flow with this signed-tag gate, and v10.0.0-rc.8 is the first tag pushed under it — first time the bug was exercised.

Made with Cursor

[github-actions]

Codex review completed — no issues found.

[branarakic]

Rebased onto current main (264a5fe3, post-rc.9 merge).

Resolution note: main has had 7 CI fixes in these files since the merge-base, including 2478f632 fix(ci): remove signed-tag requirement from npm-publish which deleted the entire Require signed annotated tag gate from npm-publish.yml. The npm-publish.yml hunk from this PR is therefore obsolete and was dropped during rebase — the gate it patched no longer exists.

The release.yml hunk is unchanged and still needed: that workflow's Require structurally signed tag (hard gate) is intact on main and still runs git cat-file -t <tag> on a checkout that lacks fetch-tags: true (verified by reading the current file). This is the same release-blocking bug hit on v10.0.0-rc.8 — and the manual-workaround tax on every release tag push including v10.0.0-rc.9.

Rebased commit: 175b176d (was 2b932263). Diff is now 7 lines in 1 file. Updated the commit message to explain the drop.

[github-actions]

Codex review completed — no issues found.