mfournier
commented
9 years ago Yes, so I actually changed this job so it never fails (simply adding unconditional exit 0's), but screwed up (twice)... I believe it works properly now.
Rationale: I wanted tighter coupling between the MultiJob tasks and their child jobs, else tracking which commit is associated with which job is a hassle. But the compromise is that child jobs are not allowed to fail, otherwise the parent MultiJob fails too.
There are currently 2 jobs which are classified under "informative": scan-build and clang-strict. So the idea is to artificially make them always succeed, because they most probably will always report errors. We care about the information this gives us, not the exit status.
https://issues.jenkins-ci.org/browse/JENKINS-26876 might be a better way to achieve this, if this feature once gets implemented in the MultiJob plugin.
I hope this clarifies a bit...
I also replaced the "master" and "pull-requests" views by a single one which only highlights the 3 MultiJobs we have. They give a much better overview of the build statuses IMHO, so this should make navigating jenkins a bit less puzzling. https://ci.collectd.org/view/tests/
In this build: https://ci.collectd.org/job/master-aggregation/15/
The overall status is "failure", because the task "master-build-on-jessie-amd64-with-clang-strict" failed, even though that task ist in the "informative" phase. I expected the overall status to be "success", because all tasks in the "touchstone", "mandatory" and "supported" phases succeeded.