> I have had multiple real problems in my life where not knowing the exact source checkout and time something was built has been a problem.
Once you know the exact source, what does it matter when the binary was built?
Once you know the exact source, what does it matter when the binary was built?
I needed this in pathological cases in the first place; think "this stuff dates from when this mature company was just a startup" kinda things. Knowing when it was built wouldn't have changed anything about the executable itself but would have helped with "which strata of old employees should I be hitting up", what other bugs were present, whether we were using a broken compiler at the time, etc.
In a perfect world, sure, none of that would matter, but.... the sibling reply from mentat is right in principle, but in practice sometimes the pathological does happen.
However, if I had to choose between knowing the exact commit and knowing the exact time, I'd certainly choose exact commit, no question. But you don't; you might as well just stick all the data in.
You don't have to choose between embedding the build time or commit information, but you do have to choose between embedding the build time or having reproducible builds. I know what I prefer, as a maintainer and consumer.
It's really nerve-wrecking (to me) when you pull down a binary from the website releases, pass it to sha256sum and gets something different than when you built the same commit from source. Usually that's because dates and times are embedded in the build, but sometimes stuff is just different depending on who built it, and that's scary.
To be fair, I'm aware that a poorly archived/copied file can lose them (especially over a network) and it's not part of `POSIX.1`. At the end of the day though I've found it's a reasonable "belt" to wear with your suspenders.
This of course could be fixed with a Nix type system (or even Nix itself), where the inputs of everything are hashed. But that’s a much more radical change than what OP is doing.
Build pipelines should be versioned as well. Correlate the application sha with the pipeline sha and you have both sources.
> And if you pull in a non-reproducible library, time will matter a lot.
I'd argue that if your application is pulling in a non-reproducible library and using it, then your application won't be reproducible until you've made the libraries you're using also reproducible. Otherwise the entire idea falls apart.
Git solves this problem by tracking all of the ingredients for you with plenty of metadata to ensure you're never baking a bad cake. Couple it with a changelog and tagging and you'll worry a lot less about bad or expired cakes.
When I see people depend on things like dates or build id's it's typically my first indication that something is wrong in the cake making process.