Report the CalVer release as the firmware version #61
Loading…
Reference in a new issue
No description provided.
Delete branch "feat/uf-18-calver-version"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Nodes reported a hardcoded
0x0001, so nothing on the bus could say which release a board runs. The field now carries the CalVer release packed as spec section 8.1 describes, and0x0000is a development build.can::version::packis the only place the shifts live;scripts/firmware_version.pyinjects the components the waybuild_id.pyinjects the commit.The release job rebuilds with the version injected rather than the build job deriving it early: that keeps the registry read and the publish inside the one job the
concurrencygroup serialises, and leaves pull request builds with no token and no version. A month past 127 releases fails the compile on astatic_assertrather than wrapping into the month bits.Tested:
pio test -e native(422 cases), both nodes andhost_simwith and without a version, the injection throughpio run -t envdump, and the malformed and over-ceiling cases failing the build.The packing is a contract with the Home Assistant integration (CCS-UHA-22), pinned by three vector cases. CCS-UF-18.
The packing, the injection, the static_assert, the vectors and the spec table all check out — 2026.09.47 -> 0x04AF, the ordering property holds, an over-ceiling counter and a malformed
CTRL_RELEASE_VERSIONboth fail the compile, and the regenerated vectors match. Three things to fix.CTRL_BUILD_IDis no longer checked on the images that ship. The release job now builds what it publishes, but the only build-id assertion is in thebuildjob, whose images are now thrown away.build_id.pyfalls back to zeros on any git error, which is why that step exists — and the release job's own build depends on a separateTrust the workspacestep to avoid exactly that fallback. AddCTRL_BUILD_IDto theVerify the release version was stampedloop; it already has theenvdumpoutput in hand. CONTRIBUTING.md line 276 also now overstates things: the build-id assertion no longer covers the released firmware.dist/is not in.gitignore.collect_dist.shis now a script a developer will run locally, and it leaves four untracked files behind. Adddist/while you are in there.The PR description. CONTRIBUTING.md and CLAUDE.md both ask for a subject line and a couple of short lines. This is six paragraphs, and the reasoning it carries is already in
version.h's comments and the new CONTRIBUTING.md section — which is where the rule says it belongs.@ -154,0 +155,4 @@# The injection fails as silently as the build id's does, so check it# landed rather than trusting it. A release the field cannot carry fails# the compile above instead: see lib/node-runtime/src/firmware_version.h.- name: Verify the release version was stampedThis checks the release version on the published images but nothing checks
CTRL_BUILD_IDon them any more — that assertion stayed in thebuildjob, whose firmware is now discarded.build_id.pyfalls back to zeros silently, so foldCTRL_BUILD_IDinto this loop: the$dumpis already captured.@ -403,6 +403,18 @@ the shortest DLC that carries all meaningful fields.| 2-3 | Firmware version, `uint16` || 4-7 | Build identifier, `uint32` (short git hash) |The firmware version carries the CalVer release, packed so that the raw `uint16`The packing table only follows
SYS_ANNOUNCE, butSYS_HEARTBEATbytes 6-7 carry the same field and a reader landing on that row has no pointer to it. Add one.Round two: all four are properly fixed, nothing new to act on.
I extracted the verify step's script from the YAML and ran it against both node environments — it passes for all four defines, including the quoted
0xb7367018ULshape. The*"'$value'"glob is anchored by the leading quote, so expecting1against a stamped11fails, as does11against111and a truncated build id against the full one; a missing define reportsnothingand exits 1. The backslash continuation inside theforlist is between words rather than inside a quoted string, so it does not hit the dedent trap the package-publish step warns about. CONTRIBUTING.md line 276 is accurate again now the release job checks both.