I'm not following your point. When I say build the same version multiple times, I basically mean rerun the build. Maybe there was a bug in the build but the code isn't changing. Each time you kick off the build for that pipeline, you will get a new buildid. Even if you change nothing and rerun a build, the build artifacts will likely not be identical. Even just an embedded datetime somewhere can make then not identical.
At some point, the latest build that has gone through your QA process will declared "ready" and promoted to release a.b.c. It's imperative that you do not run separate build for release.
Why? Because you have a brand new set of artifacts and all the testing you did previously is now out of date and you need to retest everything.
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.