On Fri, Jul 14, 2017 at 07:54:16AM -0700, Junio C Hamano wrote: > > 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. Ah, right, I didn't think about how these are racing. You'd need storage which allows some kind of atomic operation to "claim" the tree as a work-in-progress (and anybody who loses the race to get the lock would have to spin waiting for the winner to tell them the real status). I don't know if Travis's cache storage is up to that challenge. We could probably build such a lock on top of third-party storage, but things are rapidly getting more complex. -Peff
