Looking at the IBM Jenkins setup we definitely have that option under "Build Triggers" -> "GitHub Pull Request Builder" -> "Trigger Setup" Then you can "Add" the "Cancel build on update"
I'm not sure how well that would work for our setup (We would need the ability to drop a script in when it cancels the job). But it is worth experimenting with at some point. Since the IBM Jenkins polls GitHub, if there are multiple pushes to a PR in a short amount of time then Jenkins will test the 'latest' one that came in during the time window. Some folks might have noticed that behavior. In a push model, like I think LANL is using, they get notice to build every push. There might be a way to throttle that in Jenkins, I donno. On Thu, Feb 9, 2017 at 3:38 AM, Gilles Gouaillardet < gilles.gouaillar...@gmail.com> wrote: > 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 > -- Josh Hursey IBM Spectrum MPI Developer
_______________________________________________ devel mailing list devel@lists.open-mpi.org https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
