Check six things in any pull request that touches build, packaging or CI files: new timestamps or dates, unsorted output, embedded paths or usernames, unpinned tools and dependencies, downloads without checksums, and caches that cross trust boundaries. Back each with an automated test, so reviewers do not rely on memory.
Why a checklist
Reproducibility is easy to lose. One new step that writes the build date, or one new unpinned download, and two builds of the same commit stop matching. The Reproducible Builds project distils the causes into a short list of commandments, which makes a good base for review.
The checklist
| Check | What to look for | Source of the rule |
|---|---|---|
| Names and places | Username, hostname or checkout path written into output | Do not record the name of the maker or the place of making |
| Dates and times | Current time embedded anywhere | Use SOURCE_DATE_EPOCH instead |
| Order | Directory listings, hash maps or sets written out without sorting | Do all work in order |
| Randomness | UUIDs, random numbers or keys generated into output | Do not record random numbers |
| Parallelism | Steps that race and write shared output | Do one thing at a time or ensure races do no harm |
| Machine specifics | Optimisations that depend on the build machine's CPU | Do not look at build machine capabilities |
| Environment | Timezone, locale and umask differences | Keep the workspace clean of them or ensure they do no harm |
| Network | New fetches during the build | Allow for offline builds |
| Inputs | Missing record of what the build used | Take note of build inputs when publishing binaries |
Add two items that come from other Reproducible Builds pages: version strings must come from source, not from the clock or a counter, and short git hashes must have a fixed length. See the git hash trap.
Automate what you can
- Rebuild twice in CI. Build in two directories and compare SHA-256. Fail the check on mismatch.
- Vary the environment. Run the second build with a different timezone and locale, to catch leaks.
- Diff on failure. Attach the diffoscope report to the failed job, so the author can see the cause. See finding why two builds differ.
- Lockfile checks. Fail the build if the lockfile is out of date.
- Protect the build files. Use code owners on workflow and packaging files, so changes get the right reviewer.
- Review caches. Check cache keys and who can write them. See cache-mode in GitHub Actions.
What reviewers should ask
- Does this change add an input to the build? If so, where is it pinned or recorded?
- Could this value be different tomorrow, or on another machine?
- If this step fails, would we know?
A short answer in the pull request description is enough. The point is that someone asked.
Try it yourself
Safeguard's policies and gates can run rules on pull requests before they merge. Click through the demo and look at how a gate blocks a change and explains why.
Click through it at your own pace, or open it full screen.
Quick check
Do I need to review every pull request this way?
Only those touching build, packaging, CI, Dockerfile or dependency files. Path based review rules can route them.
Is a two build comparison in CI too slow?
It doubles build time for that job. Many teams run it on release branches and on changes to build files, not on every commit.
Sources
Last reviewed: 19 October 2026.
