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.

Reply via email to