Add job checking for reproducibility issues #2342
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds a set of CI jobs to try and prevent nondeterminism in the build process. While they are not a guarantee that Hubris will be reproducible, it will hopefully catch most cases where we accidentally introduce nondeterminism.
There are two new jobs, reproducible-a and reproducible-b, building the same board (I arbitrarily picked cosmo-b, it can be anything). The first job uses the standard Ubuntu runner with little to no modification, while the second job tries to mutate the build environment as much as possible to introduce sources of nondeterminism. The code of the second job is heavily commented to describe each source and how we introduce it.
Inspiration for which variations to introduce was inspired by both past personal experience and the documentation provided by the reproducible-builds project. There is a source I wanted to include (different UIDs) but didn't, and that's because running things as different users inside of GitHub Actions was breaking too many things to be worth it.
There is then a final new job, reproducible-check, that gets the artifacts from both builders and compares them with diffoscope, another tool by the reproducible-builds project. In case there are differences it will upload the diffoscope report as an artifact for analysis. This is a run where I intentionally induced nondeterminism, if you want to look at how things would be in case of a failure (there is a link to the diffoscope report in there).
If there are other sources of nondeterminism we want to try and inject let me know and I'll see how feasible it is to add them.
Fixes #2299