jenkins for master: successful linux builds now prerequisite for triggering mac and win

[Christian Lohmaier]

Hi *,

hard to put it into a concise summary, but hopefully this will explain:

Since the jenkins linux-clang bot now has code-style checks in place,
it's a waste to wait for the slow windows and mac build results in
case the build fails because of a code-style issue.

Thus to enable that, the gerrit configurations have been split into
the individual branches and master/feature-branches.

So what does it mean for you?

0) you commit a change to gerrit for master (or a feature-branch)
1) jenkins will trigger the linux builders
2 a) both linux builders finish with success → win and mac builds are triggered.
2 b) one (or both) of the linux builds fail) → jenkins will
immediately report failure and not trigger win or mac

2a) assuming an empty build-queue/buildslaves would be available:
this delay time to get results for about 15-20 minutes (the typical
build time of the clang builder)
in reality though the win/mac builders would be busy, and would not be
available right away to build in parallel with the linux ones anyway.

2b) now instead of waiting 90 minutes or more, you get failure notice
right away, and more importantly don't "steal"/waste buildtime on
mac/win - those can build other changesets in the meantime

*** ATTENTION ***
What might be irritating/misleading with this is the jenkins results page.
take e.g. https://jenkins.libreoffice.org/job/lo_gerrit/23517/ that
one failed in the linux stage, and while it shows the dots for mac and
win, those are pale/lighter and their color doesn't have any meaning
whatsoever for the current changeset (just shows result from the
previous gerrit build)

(So please don't even try overrule verification like "linux build
breaker is from master/not my change and others are fine, so
overruling verification" - the point is that others are unknown. You
must not confuse the pale dots with actual results, even when they are
not blinking :-))


The config for the release-branches doesn't have those so-called
"touchdown" builds first, they trigger all builds at once, as
code-style is assumed to be verified on the corresponding master
commit(s) already.

Another change re jenkins was that new patch revisions now
automatically cancel/abort previous patchsets. So if you're interested
in the build-result of a currently-building patchset, you need to wait
with your rebase/changes, as the build would otherwise be aborted.

If you're still reading this: Whilst doing the above changes, there
were some hiccups in the windows builds for the release-branch
verification. Specifically the windows builders did break with a
failing testArabic test in vcl.
Turns out that this was due to a longer pathname (3 characters more
than the plain gerrit one) - why a font-metric check would fail due to
path name length is the real question, but to get builds running the
paths were shortened for the release-branch config.
Also a new mac builder was added (thanks Thorsten) that had some
initial problems, but those should also be resolved now. To avoid
having connection cuts right in the middle of a build (causing it to
be marked as failed), that box is on a schedule (active from 6 am to
9pm) so it is normal for it to be listed as "suspended" during the
off-ours.

ciao
Christian