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).
On Sun, Nov 17, 2013 at 1:14 AM, Joachim Durchholz <[email protected]> wrote: > 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). On the build page there is a power button on the right that will cancel a build. > > 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/. > > 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. > > 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). 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). Aaron Meurer > > -- > 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. -- 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.
