fix(site): show release tag instead of "vunknown" version badge#227
Merged
Conversation
The site generator invoked `jamf-cli version` and parsed the first line expecting the text banner `jamf-cli <version>`. But the global `-o` default is `json`, and since #195 the version command honors it — so the bare call returns JSON, whose first line is `{`. parseVersion saw a single field, returned "unknown", and the display layer prefixed `v`, rendering "vunknown" on the deployed site. Fix: - Invoke `version -o json` explicitly and read the structured `version` field, falling back to the legacy banner for older binaries that predate `-o` support (the deploy builds the binary from the latest release tag while taking the generator from main). - Strip the git-describe `-dirty` marker so the clean release tag shows. The deploy overlays site files from main onto the tagged checkout, dirtying the tree; without this a clean tag surfaced as "v1.17.0-dirty". All build paths (deploy, release, local `make site`) now resolve to the nearest release tag, e.g. v1.17.0. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
neilmartin83
approved these changes
May 31, 2026
ktn-jamf
added a commit
that referenced
this pull request
May 31, 2026
Resolve conflict in generator/site/main.go. main's #227 landed an equivalent "parse version from JSON" fix (extractRawVersion) that also trims the bare "-dirty" marker — strictly more complete than this branch's rawVersion, which missed the clean-tag-built-on-dirty-tree case. Kept main's extractRawVersion + parseVersion; dropped the branch's redundant rawVersion. The branch's real contribution (llms.txt "For AI Agents" contract + Output Formats expansion in renderLLMSTxt) auto-merged cleanly. Both branches' parseVersion JSON test cases were retained as complementary coverage. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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
2 participants
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.
Problem
The showcase site rendered
vunknownas the version badge.Root cause is a broken implicit contract. The site generator ran
jamf-cli versionand parsed the first line expecting the text bannerjamf-cli <version>(fields[1]). But the global-odefault isjson, and since #195 theversioncommand honors-o— so the bare call now returns JSON whose first line is just{.parseVersionsaw a single field, fell into itslen(fields) < 2→"unknown"branch, andcatalog.jsprefixedv→vunknown. This affected the deployed site, since the deploy workflow makes the same flagless call.Fix
generator/site/main.go:version -o jsonexplicitly and read the structuredversionfield, with a fallback to the legacy banner for binaries that predate-osupport (the deploy builds the binary from the latest release tag while taking the generator from main, so the generator can't assume the binary speaks JSON).-dirtymarker. The deploy overlays site files frommainonto the tagged checkout, which dirties the tree — without this, a clean tag surfaced asv1.17.0-dirty.Result
All build paths now resolve to the clean nearest release tag:
git describemain(tag + dirty overlay)v1.17.0-dirtyv1.17.0make sitev1.17.0-25-g74846ff-dirtyTesting
TestParseVersioncases incl. both dirty-build scenarios; existing banner cases retained (now exercise the fallback path). Fullgenerator/sitepackage passes;go vet,gofmt,go build ./...clean.v1.17.0, applied the workflow's overlay, built the binary, ran the fixed generator →commands.jsonreports"version": "1.17.0".🤖 Generated with Claude Code