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
