make+build: Create globally-consistent, build-input identifier #863
Description
Background
- During the build process, there is a motivation to create a consistent identifier for what code and resources were used to create build artifacts/binaries.
- This identifier should communicate
- What notional code basis was used for the build
- The presence of any modifications to that code
- This identifier should communicate
- Factors affecting such an identifier:
- Root cause of
./release.shproduces tags of different lengths, across certain hosts #854 is- Inconsistent client-side git.config settings may result in globally inconsistent commit-hash abbreviation between different hosts
- a git instance's core.abbrev configuration value dictates how many characters git describe will produce
- Root cause of
The manifest file's in-situ build-artifacts identifier entries are produced here:
Line 91 in 43ac9fa
Assigned from here:
Line 33 in 43ac9fa
Called from here
https://github.com/lightninglabs/lightning-terminal/blob/43ac9fac94cd158e1b7c560555f2a7b565c307f9/Makefile#L164C30-L164C45
Proposed Solution
- Modify VERSION_TAG to use enhanced identifier
git describeDocumentation:- git describe --abbrev=40 --broken --tags --always
Design-choice interrogation
- --always
- Produce uniquely abbreviated commit object as fallback, regardless if tags precede checked-out commit
- Forces
git describeto produce the identifier, in the rare scenario, for commits which have no proceeding tags
- --broken
- When the working tree matches HEAD, the output is the same as "git describe HEAD".
- If the working tree has local modification "-dirty" is appended to it.
- If a repository is corrupt
- and Git cannot determine if there is local modification, Git will error out
- Enumerate cases in which having the build identifier note a corrupted build
- Will a git describe error exit code stop the build?
⚠️ Nomake/release_flags.mk- Modified
- VERSION_TAG = $(shell exit 1)
- Testing this patch:
- Violates needs:
⚠️ build commences rather than halt or error
- VERSION_TAG = $(shell exit 1)
- Modified
- script/release.sh
- Usage:
[snip]
release.sh build-release <build-system(s)> " - release.sh fails to assert the suitability of the tag passed to it
- No input validation performed by release.sh on inputs prior to assignment to variables
- Simulate build-release being called with an empty tag passed as argument
- Violates needs:
⚠️ build commences rather than halt or error- scripts/release.sh build-release "" "macos" "buildtags" "ldflags"
+sdb:2> scripts/release.sh build-release '' macos buildtags ldflags
e[0;32mBuilding releasee[0m
e[0;32m - Packaging vendore[0m
go: downloading github.com/btcsuite/btcd v0.24.3-0.20240921052913-67b8efd3ba53
- Impact:
- Failure to produce a release tag can occur when building in a corrupted git work tree
- Conclusion: use
--brokentag in git describe - If ‘--broken’ is passed to git describe and the worktree is corrupted, git describe appends the suffix "-broken"
- Producing a VERSION_TAG containing
--brokenindicates aberrant build environment to a developer rather than a manifest with a missing VERSION_TAG.
- Usage:
- Will a git describe error exit code stop the build?
- Enumerate cases in which having the build identifier note a corrupted build
- and Git cannot determine if there is local modification, Git will error out
Alternative Solutions
- git describe --abbrev=40 --dirty --tags
- git describe --broken --tags