2026-04-05 17:04 UTC
Replies (3)
-
@zekjur@mas.to 2026-04-05 17:06
Aside from the article itself, there’s also a repository to illustrate the technique at https://github.com/stapelberg/stampit, a README where we can collect language ecosystem build stamping status, and an agent SKILL.md to audit your fleet! :) And of course, I researched **the Nix full picture diagram** (see attached) for this article 🤯 #nix #nixos
-
@Atemu@darmstadt.social 2026-04-06 10:48
@zekjur Honestly, we should have that in the go builder by default. Perhaps even stdenv. We could then have a standard fakegit hook that returns the rev for the common rev checking commands which would work for any build process that does git integration via execve. Rev info for regular nixpkgs packages with non-flake input srcs would need to be locked along with version and src hash on update; ideally automatically and into a plain JSON file.
-
@zhenech@chaos.social 2026-04-06 11:00
@zekjur in Git, you can mark files as export-subst [1] and thus place the describe output in git-archive generated tarballs (like the ones GitHub offers) via "$Format:%(describe)$" or similar. Putting that into the VERSION file makes `git describe || cat VERSION` do the right thing in 99.999%[2] of the cases. [1] https://git-scm.com/docs/git-archive/2.29.0#ATTRIBUTES [2] not scientifically proven