Jeff, iirc, i saw build being cancelled (i was monitoring the Jenkins console) when new commits were pushed (or force pushed) to the current PR
i will make a test tomorrow it is fair that using Travis for new PR is very likely more useful than for validating all builds Cheers, Gilles ----- Original Message ----- > 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 > _______________________________________________ devel mailing list devel@lists.open-mpi.org https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
