feat(DCP-2596): show cli version in release#375
Conversation
✅ Snyk checks have passed. No issues have been found so far.
💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse. |
There was a problem hiding this comment.
Pull request overview
This PR updates the CLI’s reported version so releases (and some install methods) can display a meaningful semantic version instead of only relying on a build-time variable.
Changes:
- Add
version.Get()to compute the CLI version from-ldflagsfirst, then fall back todebug.ReadBuildInfo(). - Switch Cobra’s root command
Versionfield to useversion.Get().
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
version/version.go |
Introduces version resolution logic using ldflags and Go build metadata. |
cmd/root.go |
Uses the new version resolver for --version output. |
version/version.go
Outdated
| // GITCOMMIT is injected at build time via -ldflags (e.g. "0.0.62"). | ||
| // Defaults to "dev" when not set. | ||
| var GITCOMMIT string = "dev" |
There was a problem hiding this comment.
The variable name GITCOMMIT is now used as the primary source of the CLI version (and the comment/example show semantic versions). This is misleading for future maintainers. Consider introducing a Version variable as the canonical value (still settable via -ldflags) and keeping GITCOMMIT only as a backwards-compatible alias/deprecated name.
There was a problem hiding this comment.
Does this no longer work, and if not, can it be updated?
There was a problem hiding this comment.
make static still works unchanged. The ldflags inject GITCOMMIT as the short commit hash (e.g. 93ca342), which is not "dev", so Get() returns it immediately on the first check — the runtime/debug fallback is never reached. Same applies to make static-named in the release pipeline.
There was a problem hiding this comment.
Unless I have misunderstood what you meant?
There was a problem hiding this comment.
Might be just talking cross purposes. Fairly sure this use to work. So releases would set VERSION=xxxx make static so there was no need for code to do what we are doing here.
There was a problem hiding this comment.
Sorry so a bit a context might be useful. In local instances and builds using the binary are fine, however we noticed that when the cli is installed via Kandji we're returning prolific version dev instead of the version. It seems highly possible that Kandji isn't using them, likely using go install but looking into this now
There was a problem hiding this comment.
oic - Yeah Ideally Kandji uses the released binaries rather than building again - Cool
There was a problem hiding this comment.
Done in 0162b21 — renamed GITCOMMIT to Version in version/version.go, Makefile, and DEVELOPMENT.md. Follows standard Go export naming convention.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
31b4c45 to
200caa2
Compare
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Summary
Get()function toversionpackage that falls back toruntime/debugbuild info whenVersionis not injected via ldflagsversionFromBuildInfoguards against"","(devel)", and pseudo-versions (vX.Y.Z-TIMESTAMP-HASH) — localmake buildstill correctly showsdevGITCOMMIT→Versionacrossversion/version.go,Makefile, andDEVELOPMENT.mdto better reflect its purposeTestVersionFromBuildInfoandTestGetcovering all version resolution pathsgo install @vX.Y.Zinstalls (e.g. Kandji) showingdevinstead of the real version numberJira Ticket
DCP-2596: Fix versioning
Testing
make static(local)93ca342✓93ca342✓GIT_RELEASE=vX.Y.Z make static-named0.0.62✓0.0.62✓go install @vX.Y.Zdev✗0.0.62✓ (after new version released)make build(no ldflags)dev✓dev✓Checklist