Jeff King <p...@peff.net> writes: >> Another alternative is to simply accept that these tests are racy, and >> that the resulting test failures are rare enough that it isn't worth >> the complexity of the workaround, but adding a comment to the affected >> tests warning about the raciness is sufficient. (But I wrote this >> when I first saw and tracked down this failure; since then I observed >> it four more times... :) > > It's definitely bugged me. I'd be happy to see some solution. I've been > close to suggesting that reading apache logs is simply not robust, and > we should focus our tests on the git-visible state changes (e.g., seeing > successful requests, updated refs, etc).
Hmph, that certainly is "checking only the things that matter", which is desirable. > A side effect of that is that it would become a lot easier to support > other webservers in our test scripts (though that may still be a fool's > errand just due to the amount of custom config we seem to carry).
