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 _______________________________________________ LibreOffice mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/libreoffice
