fix(ci): fetch tags so a dispatched docs deploy renders a real version

[jamesbeedy]

One line of config. Most of this description is the evidence, because the first version of this claim was wrong and worth stating precisely.

What is broken

The navbar version badge comes from getProjectVersion() in @vantagecompute/docusaurus-theme, which shells out to git describe --tags --always. This workflow checks out at the default depth of 1.

The tag trigger is fine, which is every deploy this repo has ever run. actions/checkout resolves refs/tags/vX.Y.Z, so the tag describe needs is the very ref checked out. The live site's badge reads v0.1.6 today, correctly.

workflow_dispatch is not fine. It runs against a branch, and checkout fetches branches with --no-tags, so the clone carries no tags at all and describe falls through to its --always case.

Evidence

Replicating what actions/checkout actually runs, rather than reasoning about it:

$ git init && git remote add origin https://github.com/vantagecompute/armasec-lite.git
$ git fetch --no-tags --depth=1 origin df7388b   # main
$ git tag | wc -l
0
$ git describe --tags --always
df7388b

And the tag-ref case, for contrast:

$ git fetch --no-tags --depth=1 origin +refs/tags/v0.1.6:refs/tags/v0.1.6
$ git describe --tags --always
v0.1.6

Note that a plain git clone --depth 1 --branch main does not reproduce this: it pulls tags pointing at the fetched commit, and main here is exactly v0.1.6. That is what makes this easy to test wrong.

Impact

Latent, not live. The first dispatched deploy would have quietly replaced the version in the published header with a commit hash. The build succeeds and the site renders, so nothing catches it but someone reading the header.

Every other Vantage docs spoke (v8x, v8xgo, sdkpy, sdkgo, provider, slurm-mcp, tunnel-client, mcp-infra, lxd-autoscaler, vdeployer) already sets fetch-depth: 0. This repo was the only exception.

🤖 Generated with Claude Code