On Feb 8, 2017, at 9:34 AM, gil...@rist.or.jp wrote: > > i also noted that each time a PR is updated, a new Travis build is > started. > on the other hand, Jenkins is a bit smarter and does not build or cancel > "obsolete" PR.
Are you sure? Here's how I thought Jenkins worked: - create a PR: queue up a Jenkins job - push a change to a PR: queue up a Jenkins job So let's say a scenario like this happens: 1. jenkins is fully busy 2. jeff submits PR 1234, queues jenkins job 5678 3. jeff pushes another commit to PR 1234, queues jenkins job 5679 4. jeff pushes another commit to PR 1234, queues jenkins job 5680 5. jenkins becomes unbusy, runs job 5678 --> this does test the head of the PR branch -- not the PR as it was initially submitted 6. jenkins finishes 5678 and runs job 5679 --> this *also* tests the head of the PR branch -- i.e., exactly what was tested in 5678 7. jenkins finishes 5679 and runs job 5680 --> this *also* tests the head of the PR branch -- i.e., exactly what was tested in 5678 and 5679 I.e., my understanding was that Jenkins would do multiple redundant jobs and not be able to tell the difference between them (because of the lack of state kept between individual Jenkins jobs) I know that that *used* to be the case. Perhaps recently versions of Jenkins (or its plugins?) have made this better such that 5679 and 5680 would turn into no-ops...? Do you know if this is the case? > i think most of us cannot manually direct Travis to cancel a given build. > > fwiw, building pushes is not useless. > we recently hit a case in which the PR was successfully built, then some > other changes were made but they did not cause any conflicts from a a > git point of view, so the PR was merged. > unfortunatly, master could not build any more because there was a indeed > a conflict that git had no way to detect. I agree -- building pushes is not a bad thing for exactly the reason you cite. But if Travis has limited resources, I'm wondering if it would be better to utilize them for PRs than the uncommon case of detecting problems-upon-merge. -- Jeff Squyres jsquy...@cisco.com _______________________________________________ devel mailing list devel@lists.open-mpi.org https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
