Re: [OMPI devel] OMPI devel] Travis: one thing that might help
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 Gouaillardetwrote: > >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 >
Re: [OMPI devel] OMPI devel] Travis: one thing that might help
On Feb 9, 2017, at 4:38 AM, Gilles Gouaillardetwrote: > > Or maybe it used to be the case ... > see https://github.com/jenkinsci/ghprb-plugin/issues/379 for how to activate > this feature. LANL / Mellanox / IBM: can you guys check to see if you have this option set on your Jenkins? > Back to travis, this feature is scheduled to happen in 2017Q1, > See https://github.com/grosser/travis_dedup Good to know. -- Jeff Squyres jsquy...@cisco.com ___ devel mailing list devel@lists.open-mpi.org https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
Re: [OMPI devel] OMPI devel] Travis: one thing that might help
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 Gouaillardetwrote: >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
Re: [OMPI devel] Travis: one thing that might help
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
Re: [OMPI devel] Travis: one thing that might help
On Feb 8, 2017, at 10:15 AM, gil...@rist.or.jp wrote: > > 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 Oh, sweet. That would be good to know; thanks! > it is fair that using Travis for new PR is very likely more useful than > for validating all builds We talked yesterday on the call about possibly upgrading to a paid Travis plan to see if that could ease some of the congestion. Some of us are looking into this, and will report back on next Tuesday's call. -- Jeff Squyres jsquy...@cisco.com ___ devel mailing list devel@lists.open-mpi.org https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
Re: [OMPI devel] Travis: one thing that might help
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
Re: [OMPI devel] Travis: one thing that might help
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
Re: [OMPI devel] Travis: one thing that might help
Jeff, 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. 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. Cheers, Gilles - Original Message - > I noticed the other evening that we are doing two things at Travis: > > 1. Building pull requests > 2. Building pushes > > The 2nd one might well be contributing to our backlog (i.e., every time a PR is merged to the ompi repo, we Travis build again). > > I also confirmed with Travis that we're supposed to he able to be building 5 jobs concurrently within Travis. > > I've just turned off building pushes, so we should *only* be building pull requests. Let's see if this will help with the turnaround time on Travis builds... > > -- > 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
[OMPI devel] Travis: one thing that might help
I noticed the other evening that we are doing two things at Travis: 1. Building pull requests 2. Building pushes The 2nd one might well be contributing to our backlog (i.e., every time a PR is merged to the ompi repo, we Travis build again). I also confirmed with Travis that we're supposed to he able to be building 5 jobs concurrently within Travis. I've just turned off building pushes, so we should *only* be building pull requests. Let's see if this will help with the turnaround time on Travis builds... -- Jeff Squyres jsquy...@cisco.com ___ devel mailing list devel@lists.open-mpi.org https://rfd.newmexicoconsortium.org/mailman/listinfo/devel