Jeff King <p...@peff.net> writes: > Right, I think the right solution is some amount of peeling. Recognizing > that the commit sha1 is the same, or better yet, not bothering to retest > trees which have already been tested.
Yup, I also have a hack to avoid testing a version that is only different in insignificant way (e.g. the only difference being GIT-VERSION-GEN or Documentation/RelNotes/*) from an installed one in the script I use after each integration attempt I do, which I use a few times a day (that's "Meta/Dothem" if anybody is interested). > If we had some kind of persistent storage, we could do a quick: > ... > The "git test" script[1] uses this strategy with git-notes as the > storage, and I've found it quite useful. I don't think we can rely on > git-notes, but I think Travis gives us some storage options. Even just a > best-effort cache directory would probably be sufficient (this is an > optimization, after all). We do seem to use some persistence to order prove tests already, but I do not think it helps the common case, where my end-of-day push pushes out 'maint' and 'v2.13.3' at the same time, because the push is made with "git push --follow-tags $there maint master next pu" and the new tag happens to be at 'maint'. It would be nice if Travis runs were sequential, but I often observe that it creates jobs for these multiple branches and tags pushed at the same time, and start running a few of them.
