Documentation
¶
Overview ¶
nova-pulse enumerates bounded open work, cuts cards from templates, admits them through nova-swarm batch, and folds what comes back. It makes no model call: every token is a card's, and every cycle's reading is one PULSE line.
nova-pulse version: which build is running.
A pulse is several cards cut from one template and folded back together, and the first question after it misbehaves is which build cut the cards. Until this verb existed the honest answer was that nobody could say: `nova-pulse version` printed a hand-written "dev" that was wrong exactly at the commit after the release. So "we are all running the same nova-pulse" was a belief rather than a reading.
The version is NOT a constant maintained by hand -- a hand-maintained constant is wrong exactly when it matters, at the commit after the release, where it still names the release. It is read from the build itself, in this order:
-ldflags "-X main.version=..." what the release workflow stamps: the tag, exactly the module version what `go install ...@v1.2.3` records for itself the vcs stamp <utc build time>-<12 hex of the revision>[-dirty] devel a build with none of the above, SAYING it has none
The middle two come from debug.ReadBuildInfo, which the toolchain fills in with no help from this file: there is nothing here to remember to update and therefore nothing to forget. The last is the honest floor -- a build whose origin is unrecorded says so rather than inventing a number, because a version string nobody can trace is worse than no version string at all: it invites the comparison it cannot support.
ONE LINE, FOUR TOKENS. Every field goes through oneline.Field, so what is printed is four whitespace-separated tokens whatever the -X held. A version stamped with a newline or a space in it would otherwise make the one line that says which build is running say two things, or say a build time as if it were an architecture -- and the -X value is the one field here that comes from outside the toolchain.
Source Files