Feature #5630: Reproducible builds
Topic branches that lag behind their base branch don't build reproducibly with mergebasebranch build option
intrigeri wrote on #12633#note-36:
I think there's a bug in the handling of the base branch merge or something related: https://jenkins.tails.boum.org/view/Tails_ISO/job/reproducibly_build_Tails_ISO_bugfix-14796-topicons-position/8/artifact/build-artifacts/diffoscope.html shows differing (merge) commit IDs, while the build logs pretend we're merging the exact same commit ("at commit ..."). Neither of these two commit IDs are in the official tails.git, hence my guess that a different merge commit ID is created for some reason unknown to me. I don't know what's going on here but it seems fishy. Please investigate and if this is Someone Else's Problem™ file a ticket for them, otherwise fix it. I suspect it would help debugging if we passed
git merge, and/or displayed the ID of the resulting merge commit, or similar.
I think I've got it: two otherwise identical merge commits done at different times get different IDs. So if I got it right:
- base branches are not affected by this bug, which is nice
- any topic branch is affected by this bug only if it is lagging behind its base branch; that's a rather common case so it feels wrong to report such confusing info to the reviewer; it's easy to workaround (merge base branch,& push) but then you have to wait about 2h20min for the next results, IMO our already painful (some would say "bureaucratic") reviewe'n'merge process really does not need to be made more cumbersome.
I've played locally with using faketime to workaround this problem and it seems to work fine:
faketime -f "YYYY-MM-DD hh:mm:ss" git merge --no-edit $whatever always creates the same merge commit ID. Note that
-f is important otherwise the clock keeps running and if for some reason things get slow, then the commit can be created after the specified timestamp.
In passing, too bad
git merge has no
--date option, while
git commit does.
Fix reproducibility of builds of topic branches that lag behind their base branch with the mergebasebranch build option enabled (refs: #14946)
Two otherwise identical merge commits done at different times get different IDs,
and we happen to embed in the ISO the ID of the commit we're building from.
#2 Updated by intrigeri almost 2 years ago
- Subject changed from Our CI can't reproduce builds of topic branches that lag behind their base branch to Topic branches that lag behind their base branch don't build reproducibly with mergebasebranch build option
- Category changed from Continuous Integration to Build system
(This is not specific to our CI.)
#7 Updated by intrigeri almost 2 years ago
- Assignee changed from intrigeri to anonym
- % Done changed from 10 to 50
#11 Updated by bertagaz almost 2 years ago
- Status changed from In Progress to Fix committed
- Assignee deleted (
- % Done changed from 50 to 100
- QA Check changed from Ready for QA to Pass
Taking over the reviewing as part of the follow up of #12633.
Good catch, as said on IRC, I would have spent time trying to hack the merge in the build process, rather than think about the timedate affecting the merge. So I've merged it just in time for 3.3.