Exposing Git Information in Rust Binaries Built With Nix
12 points by jeezy
12 points by jeezy
In the past I had a similar issue with an app reporting its version and git ref... which would mean that tests written up in Bazel would not be able to cache results because the git ref would always change!
Ended up with the tests being run with the version being a "fake" git ref... kinda hard to do anything else in that scenario IMO. You do open the floodgates a bit to the reality that your test environment is never going to be exactly identical to the prod one. But you can still try
Yeah… one trick is to have an “expensive” derivation that doesn’t depend on the hash, then a cheap one that wraps that and only sets the hash (by e.g. calling the underlying executable with an env variable set). That way, the expensive stuff (e.g. compiling and testing the project) can still be cached.
The branch does not matter. There is no difference between the source tree of a commit "deadbeefdeadbeefdeadbeef" on master, and the same commit on a feature branch, so why should there be a difference in the build output?
It might save you a significant effort when triaging an incoming error report: you see instantly (and presented in a more reliable and consistent way than whatever a human person would write) whether it was built from bleeding edge branch vs stable release / bugfix branch vs an experimental feature branch.
Commit hash usually[^1] has the same information, but you need to look that up and lose opportunity to immediately respond "oh, you're running a bleeding edge build that had breaking changes in this feature, look at this pull request to see how to update your config". Branch/tag + timestamp is legible information that's good to have in an issue report.
[^1]: Not always, though. If your workflow involves rebases, the commits in the middle of unmerged feature branches are likely to be lost. If you squash feature branches when merging, they're guaranteed to be lost. Name of the now-merged branch would still be a meaningful clue though.
I generally embed the output of git describe, which identifies the most recent tag, how many subsequent commits, and whether the working tree is dirty. I also include the commit timestamp and hash. (Not the build timestamp because that isn’t reproducible.)
I solved this once by including the version in a file in the source tree, so the build system would simply pick it up from that file. It would be nice if this could be modeled with Git tags, but sadly there's not really a way to get an immutable reference to "this commit and all the refs pointing to it in this moment" in Git.