Reproducible build CI job uses the HEAD of the current branch instead of the commit the 1st build was built from

Since a few months, reproducibly_build_Tails_ISO_* jobs started failing when they shouldn’t. I think this happens every time the branch the job is about was updated in our official Git repo, between the time the 1st build started and the time the 2nd build did. This creates lots of noise on the RMs list and decreases my confidence in these jobs’ results, which is sad.

I looked closer at https://jenkins.tails.boum.org/view/RM/job/reproducibly_build_Tails_ISO_devel/613/ today and there we see that the 2nd build used a different commit than the 1st build: build-tails did reset the tree to the commit the branch was cloned at, i.e. its latest state in our canonical repo, while it should have reset the tree to the commit used by the 1st build, which Jenkins pretends is the current HEAD of the branch being (re)built. It seems that the recent optimizations in build-tails (done as part of #16476 (closed)) override the trick we have on Jenkins for this (checkout_upstream_job_branch in https://git.tails.boum.org/jenkins-jobs/tree/macros/builders.yaml).

I suspect these optimizations gain us very little so I’ll try reverting them, will measure the impact, and if they don’t matter much I’ll try reverting them to see if it fixes this bug.

Feature Branch: bugfix/16730-have-reproducible-build-attempt-use-same-commit-as-first-build, https://salsa.debian.org/tails-team/tails/merge_requests/22

Related issues

• Related to #16476 (closed)
• Blocks #16209

Original created by @intrigeri on 16730 (Redmine)