Am 17.11.2013 18:24, schrieb Aaron Meurer:
I guess the Travis queue is a little backed up right now. I don't know
if there's much we can do about it (after all, it's a free service, so
we get what we get).
Heh. I guess they'll be happy if we try to keep the load down by
ourselves, but, basicaly, yeah.
1) Interactively, cancel a Travis run triggered by one of your own commits
(I doubt Travis would allow cancelling somebody else's tests).
On the build page there is a power button on the right that will cancel a build.
I'm not seeing that. There's the wheel dropdown that allows me to
"regenerate key", that's all.
2) Let the Travis test script abort itself if it detects a new commit on the
branch it's running tests for.
The abort should trigger a "grey" status in Travis; Travis does not
currently offer a way to do that, the best approximation would be waiting
for keyboard input, which probably still ties up a Travis VM for 10 minutes.
Maybe the best approach for now would be to simply fail.
I don't know if this is possible. You should ask at
https://github.com/travis-ci/travis-ci/issues/.
Done.
I think what we could do is to insta-fail if the test script detects a
newer commit in the current branch. I bet there's a git subcommand to
test exactly that :-)
As long as contributors understand that a failure isn't trouble if they
pushed another commit in the meantime, we should be fine.
3) Priorize the Travis queue differently: Do not run tests by order of
commit, round-robin them by committing user. So if somebody adds 10 commits
in quick succession, he won't monopolize the queue for the next 10 hours but
gets interleaved with commits by other persons.
Again, you should ask the Travis guys.
Not an option already? Ah well... then I guess manipulating the work
queue is out of the window.
4) Do not submit to Travis if the commit comment says something like
"@notravis". It won't allow retroactive cancelling, but at least somebody
adding a series of commits will be able to mark all commits but the last one
as "do not test".
([ci skip] from http://about.travis-ci.org/docs/user/how-to-skip-a-build/
controls skipping on a per-pull-request basis, which can help, too.)
5) Run tests in reverse chronological order. (Not good but slightly better
than the current situation.)
I don't think that would work. You'd basically turn your FIFO to a
FILO, which means that some commits may take forever until they are
tested (until the queue clears).
Yeah, it's a bad option. It's slightly better because it doesn't punish
the rare committers so badly, but that's all.
I think we do want the queue to clear occasionally. If it doesn't, we're
going to pile up a backlog of commits to test.
(I suspect that Travis doesn't test individual commits, but just the
last commit of each push. The response of a Travis developer hints in
that direction.)
It's worth noting that you can enable Travis testing in your own
personal repository. If you do this, it will test commits even if they
aren't in a pull request. I'm not sure how it affects queueing (I
believe it avoids testing the same commit twice, but I'm guessing you
get your own personal queue).
Hm. I'm a bit uneasy about setting up my own Travis account - I don't
know how much work that would be.
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sympy.
For more options, visit https://groups.google.com/groups/opt_out.
