3 ms·
> 3. Build your binaries once. Assuming your builds are solidly reproducible like they should be, how do such differences "sneak in"? Granted, truly reproduci
by Cheezmeister 11y ago
> 3. Build your binaries once.
Assuming your builds are solidly reproducible like they should be, how do such differences "sneak in"?
Granted, truly reproducible builds in the first place are Really Hard(tm).
- paulstovell 11y agoWe put an explanation here (hope it's OK to post the link): https://octopus.com/blog/build-your-binaries-once https://octopus.com/blog/build-your-binaries-once A real world example of this is that when .NET 4.5 shipped, the compilers in .NET 4.5 for 4.0 code produced different output than the .NET 4.0 compilers would have. So installing a system-level update on Windows on a build server would mean Test and Production got different results: http://blog.marcgravell.com/2012/09/iterator-blocks-missing-methods-and-net.html http://blog.marcgravell.com/2012/09/iterator-blocks-missing-... Also, releases move through environments at different times: Monday: 1.0 goes to Test Tuesday: 1.1 goes to Test Wednesday: 1.0 goes to Prod Between 1.0 and 1.1, perhaps you updated Node, or went to Python3 - so your build server had to be updated. Reproducing Monday's build is going to be more difficult the more time that goes by. As you said, truly reproducible builds are hard. Why not just zip the artifacts and use the same files, instead of rebuilding?
- manojlds 11y agoDocker for CI will help. Update your base image when you upgrade Node/Python.