Jeff, Or maybe it used to be the case ... see https://github.com/jenkinsci/ghprb-plugin/issues/379 for how to activate this feature.
Back to travis, this feature is scheduled to happen in 2017Q1, See https://github.com/grosser/travis_dedup Cheers, Gilles Gilles Gouaillardet <gil...@rist.or.jp> wrote: >Jeff, > > >i made the test and it seems i got it wrong ... > >no travis build is cancelled when new commits are pushed into a PR :-( > > >i could only note Mellanox Jenkins has a "stop" icon, so a build can be >manually cancelled. > >LANL Jenkins nor Travis offer this option. > > >Sorry for the confusion, > >Gilles > >On 2/9/2017 12:15 AM, gil...@rist.or.jp wrote: >> 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 >> > >_______________________________________________ >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
