crewship version
Prints the binary’s build identity: version, commit SHA, build time, whether
the tree was dirty, Go runtime, and OS/arch. First command to run on any new
install to confirm what you actually installed.
With --remote, it also asks the configured server which build it is
running — the only way to tell a stale deployment apart from a stale CLI.
Output
version alone does not identify a build. Every binary an
-ldflags-less go build has ever produced calls itself dev — including
every build dev.sh makes for a dev slot. That is why the commit is
resolved from the embedded VCS metadata when the link-time flags are
absent: it is the only source that answers on that path, and it is the one
path where “which build is this?” actually gets asked.
A build made inside a nested git worktree needs a stamping build driver.
The Go toolchain only recognises a repository by a .git directory, and a
linked worktree’s .git is a file — so for a worktree that lives inside
its parent clone’s working tree, the embedded vcs.* metadata describes the
parent clone: a commit that was never built, and a dirty flag from a
different tree.make build and ./dev.sh ask git directly (scripts/build-stamp.sh) and
stamp the answer, so binaries they produce are correct anywhere. A bare
go build ./cmd/crewship in such a worktree is not — use one of the two, or
pass the flags yourself: --remote: what is the server running?
schema is the highest migration the server binary can apply. Past the
closed legacy sequential block a migration version is a YYYYMMDDHHMMSS
timestamp, so the number also dates the newest schema change that build
contains. A running server has already migrated its database up to it.
Requires auth (crewship login) and honours the usual target resolution —
--server, CREWSHIP_SERVER, --profile, then the config default. Note
--server keeps its normal meaning (the target URL); the boolean is
--remote:
Two things this answers that nothing else did:
- Did the deployment land? Compare the server’s
commit against what
origin/main is at. A slot that silently stopped tracking a branch shows
a build older than the merge immediately, instead of after an hour of
archaeology through container configs and agent prompts.
- Which side is stale? A missing API field is either a server that has
not been redeployed or a CLI that has not been updated. The two blocks side
by side settle it without guessing.
Without --remote the command touches no network at all — it is the first
thing you run on a broken install, and a dial here would turn a local
question into a timeout.
Comparison with --version flags
Crewship deliberately does not support crewship --version or
-v as version probes. -v is taken by --verbose (which start
uses) and a top-level --version would conflict with sub-command
flag parsing. Use crewship version as the single, unambiguous way.
Programmatic version checks
Use --format json rather than parsing the human output:
The server key is absent entirely without --remote. dirty is null
when the build carries no VCS metadata — treat null as “unknown”, not as
“clean”.
A deploy check, in one line:
The underlying endpoint is GET /api/v1/system/version
(reference); its
latest / newer / url fields drive the update-available banner in the
web UI.
Update available?
crewship version does not check for new releases, with or without
--remote. The update-availability banner is printed by
crewship doctor and logged at boot by
crewship start; both call internal/update.Check.
Suppress that check via env:
The check is an HTTP GET to the GitHub Releases API, cached 24h, and
skips silently for version=dev (local go build / go run).
crewship doctor — full pre-flight diagnostic, including
the local database’s migration version.crewship start — boot flow that logs the same
version string at INFO level.- Install — what each install path gives you.
