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
