Bug #12611

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

Added by intrigeri almost 3 years ago. Updated almost 3 years ago.

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


Feature Branch:
Type of work:
Affected tool:


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 #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 ;)

Associated revisions

Revision f6a55372 (diff)
Added by anonym almost 3 years ago

Build system: don't pre-build the wiki when mergebasebranch is enabled.

When pre-building the wiki, we modify the PO files which results in a
conflict from the base branch merge in case it modifies the same

Will-fix: #12611

Revision 17185516
Added by intrigeri almost 3 years ago

Merge remote-tracking branch 'origin/bugfix/12611-mergebasebranch-dont-pre-build-wiki' into testing (Fix-committed: #12611)


#1 Updated by intrigeri almost 3 years ago

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 almost 3 years ago

  • 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 almost 3 years ago

  • 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 almost 3 years ago

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

Thanks a lot! :)))

#5 Updated by anonym almost 3 years ago

First build successful:

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

#6 Updated by intrigeri almost 3 years ago

  • Status changed from In Progress to 11
  • % Done changed from 40 to 100

#7 Updated by intrigeri almost 3 years ago

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

#8 Updated by intrigeri almost 3 years ago

  • Status changed from 11 to Resolved

Also available in: Atom PDF