I'm currently hunting a very annoying problem in that tests run on my
machine but not on Travis.
When monitoring the Travis queue, I'm seeing 14 runs waiting ahead of my
next test run. Which means I'll have to wait another 14 hours (roughly)
before my own tests even begin to run. Which is a frustrating because
it'll stall my investigation of Travis-related problems for another day.
Of the 14 runs, 10 are for commits that were quickly superseded by
others from the same person (4 raoulb, 6 asmeurer).
Given that splitting commits into as-small-as-logically-possible commits
is a good practice, I'm wondering whether there's a way to prevent
Travis from unnecessarily running commits.
Heck, I'd like to retract my last Travis run, too, since something
failed in an entirely unexpected area which I found out only after the
commit.
Is there a way to make one of the following things happen? Each would help:
1) Interactively, cancel a Travis run triggered by one of your own
commits (I doubt Travis would allow cancelling somebody else's tests).
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.
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.
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.)
--
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.