The OSX builders are unreliable, often down for hours or days at a time. This often means that they are (by default) blocking PR merges -- we have to use our superuser bits to override and merge over top of the OSX failure.
Furthermore, most PRs will not fail _only_ on OSX, since we also test with clang on linux. Other than catching defects from build system refactoring, the build isn't adding much value. And given recent evidence, it's not even doing that well, and we need to rely on hand-testing from RobotLocomotion group for OSX build changes.
Given all of the above, I think the cost-benefit of having pre-merge OSX testing is against it, and we should remove it from the jenkins matrix until the builds are healthy again. (We would still keep it as a supported configuration, and keep the post-merge tests enabled; just disable it for PRs.)
Seeking @david-german-tri and @RussTedrake for comments.
OS X builds are going to be off for a while while I diagnose the cause of the current issues. Worst case, I have to re-build the VM image.
I agree.
I'm of mixed opinions on this. I guess since we should be able to kick off OSX builds manually on a PR, that should be sufficient. I've generally had some awareness of when an OSX build would be important (e.g. adding a new external). I'd prefer to leave OSX builds on in pre-merge if we can make them stable, but...
Yes. I expect this change increases the burden of OSX-sensitive PRs, because the author has to opt-in to OSX testing.
However, it means that OSX builders will be less loaded, so when you do care, you'll get a faster response (assuming they are working at all).
How exactly would one opt-in to a pre-merge test?
I'm guessing one will have to manually schedule an identical test by following these instructions: http://drake.mit.edu/jenkins.html#run-specific-build.
Yes.
We could also tag such PRs "configuration: mac" to indicate to the audience that the osx build should pass before merging.
If it is really the case that the linix clang builds catch almost everything in practice, and we establish this policy, i'm ok with it.
How exactly would one opt-in to a pre-merge test?
I can set up a trigger on Jenkins so that you can just comment on the issue. You would then see an extra build in the status.
@jamiesnape Neat! Could we have the trigger be "configuration: mac" instead of a comment?
At moment, the plugin only listens for comments. I will look into labels, but it may require writing that into the plugin.
Alright. Comments can serve for now.
OS X builds have been removed. An on-demand job triggered by comments will be available by tomorrow evening.
Most helpful comment
OS X builds have been removed. An on-demand job triggered by comments will be available by tomorrow evening.