Bug #12611

Website build before merging the base branch often breaks ISO builds on Jenkins

Added by intrigeri 2017-05-27 09:42:56 . Updated 2017-06-12 16:07:42 .

Continuous Integration
Target version:
Start date:
Due date:
% Done:


Feature Branch:
Type of work:

Affected tool:
Deliverable for:


Here’s what happens: the website is built from the topic branch (vagrant/provision/assets/build-tails), which updates PO files; then merging of the base branch (auto/build) fails as the PO files update has been done and pushed there already, but nobody merged the base branch into all corresponding topic branches yet. Every time I see this happen on Jenkins, I merge the base branch into the topic branch and push it. I’ve had to manually repair such breakage very often recently. That’s a PITA, and we really should not rely on me baby-sitting our Jenkins builds this much, for our dev & QA process (e.g. I just did that for the Feature #5630 branch to ensure anonym has enough data when he’ll evaluate it).

I think this scenario is quite common: pretty often we don’t bother updating website PO files after merging doc changes into testing/devel, to avoid conflicts when merging master into them.

I don’t know if this is a regression brought by the updated Vagrant build system, or if I’ve just seen it often recently due to the activity peak caused by the doc update for 3.0. Whatever :)

The corresponding code has this explanation:

# Since $TAILS_GIT_DIR is guaranteed persistent until the VM is shutdown
# let's build the website while there so it is cached throughout
# the session. This will make rebuilds after failures much faster.

We don’t benefit from it on Jenkins currently AFAIK, and IMO it would be a bad idea to use this cached build there anyway. So, how about we make this step run only if TAILS_MERGE_BASE_BRANCH is not set? This would fix the problem on Jenkins, while keeping the cache feature for local builds by developers who most likely don’t set mergebasebranch (there’s no guarantee that their base branch is up-to-date so the resulting behavior seems too unpredictable to use in practice — and if anyone used that, I bet they would have reported this bug earlier ;)



#1 Updated by intrigeri 2017-06-01 19:27:44

FTR I’ve stopped workaround’ing this problem on all topic branches today: it’s a waste of my time, and I bet it already took me way more time than fixing the root cause of the problem. I’m happy to implement the suggested fix myself if you agree with it.

#2 Updated by intrigeri 2017-06-01 19:29:29

  • Priority changed from Normal to Elevated

(Reflecting how annoying it’ll soon become, once nobody deals with it every day behind the curtain and makes the problem much less painful for everyone else.)

#3 Updated by anonym 2017-06-01 20:10:34

  • Status changed from Confirmed to In Progress
  • Assignee changed from anonym to intrigeri
  • % Done changed from 0 to 40
  • QA Check set to Ready for QA
  • Feature Branch set to bugfix/12611-mergebasebranch-dont-pre-build-wiki

I figured it would be fastest if I just implemented it, so we avoid another trip. It’s not tested, but should be safe to deploy. I mean, it shouldn’t make things worse unless there is a syntax error.

#4 Updated by intrigeri 2017-06-01 21:40:09

  • Target version changed from Tails_3.1 to Tails_3.0

Thanks a lot! :)))

#5 Updated by anonym 2017-06-02 01:18:30

First build successful: https://jenkins.tails.boum.org/job/build_Tails_ISO_bugfix-12611-mergebasebranch-dont-pre-build-wiki/1/

And the log shows that the wiki wasn’t pre-built.

#6 Updated by intrigeri 2017-06-02 06:17:35

  • Status changed from In Progress to Fix committed
  • % Done changed from 40 to 100

Applied in changeset commit:171855168b5fdc6bb01724ab6f7bfe58e0093bd0.

#7 Updated by intrigeri 2017-06-02 06:17:56

  • Assignee deleted (intrigeri)
  • QA Check changed from Ready for QA to Pass

#8 Updated by intrigeri 2017-06-12 16:07:42

  • Status changed from Fix committed to Resolved