3 ms·
Often the version string is baked somehow into the artifact. If it contains volatile data that is not functionally dependent on the source (the when and how) it
by weinzierl 2y ago
Often the version string is baked somehow into the artifact. If it contains volatile data that is not functionally dependent on the source (the when and how) it prevents the build from being reproducible.
My opinion is that the pure semver should be part of the source and be baked in the artifact. Date and build metadata should be recorded close but separate from the artifact.
- akpa1 2y agoIf you have to include a date, the best thing to do while keeping builds reproducible is to use the date of the commit you're building. I quite like this approach, especially since it's fairly simple and readily available to get hold of too. Eg: git show --no-patch --format=%ci HEAD or %ct if you want a Unix timestamp.
- hifromwork 2y agoOh, I like that solution! My problem with dates is indeed lack of reproducibility. The only issue here is that it's not technically monotonic - both commit and author date are changeable: $ git init Initialized empty Git repository in /tmp/kk/.git/ $ echo a > a; git add .; git commit -m a $ echo b > b; git add .; git commit --date="Wed Feb 16 14:00 2011 +0100" -m b $ echo c > c; git add .; GIT_COMMITTER_DATE="Wed Feb 16 14:00 2011 +0100" git commit -m c $ git lg * 523aa1a - (2024-11-28) c - user (HEAD -> master) * cbdbbbe - (2011-02-16) b - user * 1055e1e - (2024-11-28) a - user $ git show --no-patch --format=%ci HEAD 2011-02-16 14:00:00 +0100 But I guess if you use a typical pull-request based workflow this won't happen in practice.