If I wanted to grab a particular build, I just request to some git repo or Nix cache and just let Nix install it, or if there isn’t a pre-built version, Nix can compile with the exact variables.
At the end, Nix can compare the hashes between what the source says and what it built/installed.
If there are new artefacts, Nix will create a separate derivation with a different hash.
Each time you kick off the build for that pipeline, you will get a new buildid.
You shouldn’t be able to rerun the same build with different results.
Nix has a whole host of hermetic build methods to prevent this from happening at all.
Check out Nix. It removes a lot of problems in builds.
It turns building from an unpredictable ritual to a mathematical, deterministic algorithm.
You managed to agree with me without understanding the discussion.
Lets say you run a build that compiles v2.0 branch and store the artifacts as myproduct-2.0.2.tar.gz
You deploy that to your QA environment. Your testers have it and when they are done the results "looks good, time to release it to prod.
What you should do is take your build an promote it to released status. Now this can be picked up by customers or deployed to prod.
But, believe it not, there are people that branches named dev, test, prod. So when they complete testing on the artifacts above, they run another build on the prod branch and either release that to customers or deploy on internal prod.
You’re saying the same thing as me – when they do that prod build, its not the same artifacts as they tested in QA. In fact, anything you tested previously is no longer relevant because you have a new build.
Since you brought an OS package manager into the discussion (which wasn’t what I thought was being discussed), let’s look at from a fedora/rpm perspective. All I’m saying is that after building an rpm they push it through the pipeline. It goes to updates-testing and then later updates. The exact same rpm is promoted to updates from updates-testing. They do not build a new rpm for updates repo.
I see many people who have separate builds for each environment.
Listen, I’m a Nix person.
I don’t understand how it works in whatever system you use or any other system, but here’s how I understand about this.
A Nix build/derivation is labeled by the hash of all the variables put into building it.
For example, compiler flags, config, architecture, which version, etc.
It is stored in the format
/nix/store/[Hash]-[Derivation Name]-[Version Number]/.Example:
/nix/store/b6gvzjyb2pg0kjfwrjmg1vfhh54ad73z-firefox-33.1/If I wanted to grab a particular build, I just request to some git repo or Nix cache and just let Nix install it, or if there isn’t a pre-built version, Nix can compile with the exact variables.
At the end, Nix can compare the hashes between what the source says and what it built/installed.
If there are new artefacts, Nix will create a separate derivation with a different hash.
You shouldn’t be able to rerun the same build with different results.
Nix has a whole host of hermetic build methods to prevent this from happening at all.
Check out Nix. It removes a lot of problems in builds.
It turns building from an unpredictable ritual to a mathematical, deterministic algorithm.
All it takes is a compiler embedding a timestamp somewhere in the output. You are aware that repeated builds is a pretty big effort right? In fact Fedora 41 has a change to make sure rpm builds are reproducible: https://fedoraproject.org/wiki/Releases/41/ChangeSet#Reproducible_Package_Builds
It is not the same build.
A variable (a timestamp) is being changed, so by definition it is not the same build.
You managed to agree with me without understanding the discussion.
Lets say you run a build that compiles v2.0 branch and store the artifacts as myproduct-2.0.2.tar.gz
You deploy that to your QA environment. Your testers have it and when they are done the results "looks good, time to release it to prod.
What you should do is take your build an promote it to released status. Now this can be picked up by customers or deployed to prod.
But, believe it not, there are people that branches named dev, test, prod. So when they complete testing on the artifacts above, they run another build on the prod branch and either release that to customers or deploy on internal prod.
You’re saying the same thing as me – when they do that prod build, its not the same artifacts as they tested in QA. In fact, anything you tested previously is no longer relevant because you have a new build.
Can we both agree this debate is getting a bit long?
Anyway, the debate made me think a lot about this stuff.
I hope I encounter you online again, some day…
Since you brought an OS package manager into the discussion (which wasn’t what I thought was being discussed), let’s look at from a fedora/rpm perspective. All I’m saying is that after building an rpm they push it through the pipeline. It goes to updates-testing and then later updates. The exact same rpm is promoted to updates from updates-testing. They do not build a new rpm for updates repo.
I see many people who have separate builds for each environment.
Nix is not an OS package manager by default.
It is a system for reproducible builds that can have many uses.
One example is NixOS, a system for reproducible system states.
Nix on its own is more like deterministic Make.