git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] travis-ci: run previously failed tests first, then slowest to fastest

From
Jeff King <peff@peff.net>
Date
Jan 19, 2016, 23:06 UTC
Message-ID
<20160119230633.GA31142@sigill.intra.peff.net>
In-Reply-To
<xmqqio2p89mb.fsf@gitster.mtv.corp.google.com>
On Tue, Jan 19, 2016 at 02:53:00PM -0800, Junio C Hamano wrote:
Show 15 quoted lines
> Junio C Hamano <gitster@pobox.com> writes:
> 
> > This is cute, but isn't it useful even outside Travis's context?  I
> > am not suggesting to touch anything other than .travis.yml file in
> > this patch, but if I wanted to get the benefit from the idea in this
> > patch when I run my tests manually, I can just tell prove to use the
> > cached states, no?
> 
> It seems that exporting something like
> 
>     GIT_PROVE_OPTS="--timer --state=slow,save -j8" 
> 
> when running "make DEFAULT_TEST_TARGET=prove test" does give me the
> same benefit by leaving the stats from the previous run in t/.prove
> when making the test scheduling decisions.

Yes, I've been using this on my local machine for years (which is why I suggested it to Lars for the Travis build). I have also noticed that my test runs take about as much time as the longest-running test, and do not fully utilize all of my processors. I suspect we could drop the run-time of the test suite substantially by splitting a few of the longer tests.

You also wrote earlier:
Show 5 quoted lines
> IOW, I am confused by the beginning of the log message that says
> this is taking advantage of "the Travis-CI cache feature".  This
> improvement looks to me like using the feature of "prove" that
> allows us to run slower tests first, and does not have much to do
> with Travis.

The interesting Travis feature we are using is that we are allowed to store some data from run-to-run. So we use the Travis feature that lets us use the prove feature. :)

Show 6 quoted lines
> One thing I noticed but didn't dig further to fix was that this
> "prove --state" business did not seem to work well together with
> 
>     make T="...list of tests..." test
> 
> that limits the set of tests to perform.

Right, it does not do what you want. The "prove --state" feature is not just about ordering, but also about selecting. When run via "make", we always give prove the full list of tests. But you can also do:

  prove --state=failed
manually to just run whatever failed on the last run.

I don't know if there is a way to tell prove "use the state for ordering, but don't otherwise select from it", which would do what you want above.

You can also note that if we ever delete a test script, it will still be mentioned in prove's state file. I think prove is smart enough to realize it went away and not bother you.

-Peff
Previous: Junio C HamanoNext: Junio C Hamano
Message 34 of 41 in “travis-ci: run previously failed tests first, then slowest to fastest”
  1. travis-ci: run previously failed tests first, then slowest to fastestlarsxschneider@gmail.com, Jan 19, 2016
  2. Jeff KingJan 19, 2016
  3. Junio C HamanoJan 19, 2016
  4. Mike HommeyJan 20, 2016
  5. Junio C HamanoJan 20, 2016
  6. Jeff KingJan 20, 2016
  7. Lars SchneiderJan 20, 2016
  8. brian m. carlsonJan 22, 2016
  9. Jeff KingJan 22, 2016
  10. Jeff KingJan 22, 2016
  11. Thomas GummererJan 24, 2016
  12. Junio C HamanoJan 24, 2016
  13. Junio C HamanoJan 24, 2016
  14. Thomas GummererJan 25, 2016
  15. Junio C HamanoJan 25, 2016
  16. Junio C HamanoJan 25, 2016
  17. Clemens BuchacherJan 27, 2016
  18. Junio C HamanoJan 27, 2016
  19. Junio C HamanoJan 27, 2016
  20. Clemens BuchacherJan 28, 2016
  21. Junio C HamanoJan 28, 2016
  22. Clemens BuchacherJan 30, 2016
  23. Junio C HamanoFeb 1, 2016
  24. Clemens BuchacherFeb 1, 2016
  25. Junio C HamanoFeb 2, 2016
  26. Junio C HamanoFeb 3, 2016
  27. Torsten BögershausenFeb 1, 2016
  28. Torsten BögershausenJan 28, 2016
  29. Thomas GummererJan 25, 2016
  30. Jeff KingJan 20, 2016
  31. Lars SchneiderJan 20, 2016
  32. Junio C HamanoJan 19, 2016
  33. Junio C HamanoJan 19, 2016
  34. Jeff KingJan 19, 2016
  35. Junio C HamanoJan 19, 2016
  36. Jeff KingJan 19, 2016
  37. Junio C HamanoJan 19, 2016
  38. Jeff KingJan 19, 2016
  39. Johannes SchindelinJan 20, 2016
  40. Lars SchneiderJan 20, 2016
  41. Junio C HamanoJan 20, 2016

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.