The testbot used to give reliable pass/fail results for Drupal 7 core patches, but lately there are lots of intermittent failures. Anecdotally, I think this only occurs when the testbot is retesting an already-RTBC patch, although I could be completely wrong about that.
Here are a couple examples of random failures:
-
#2186281-4: Adding a library without a version number causes 'Undefined index: version in drupal_get_library()'
https://qa.drupal.org/pifr/test/717678 -
#952394-126: "No available releases found" - fetching update information exceeds timeout
https://qa.drupal.org/pifr/test/702793
In both cases the failures are clearly unrelated to the patch (and will go away if the test is rerun).
If you look at the test logs, you can see it's a different failure with a different underlying error for each (DatabaseSchemaObjectExistsException for the first, and PDOException for the second). However, what they have in common is that in both cases there seems to be a severe mismatch between the state of the test database and what the code thinks should be there (missing database tables, or trying to create a database table during install that is already there).
Comments
Comment #1
sunComment #2
jthorson CreditAttribution: jthorson commentedOnce the patch is re-tested, I have no visibility into the actual failure ... now that I'm back from vacation, there's really no way for me to look into this.
That said, tonight I did find an issue on testbot 664, which would be one of three testbots dedicated to D7 tests ... there was a frozen long-running (i.e. weeks) git fetch process chugging away on the server; so that bot wasn't 100% sane.
That's not to say that this was definitely the cause or even potentially related ... but after cleaning that up, hopefully things will be a bit more stable.
In any case, next time you see this, ping me in IRC so that I can flag the test run and look into the actual errors.
Comment #3
David_Rothstein CreditAttribution: David_Rothstein commentedThanks. Yeah, I didn't realize that when a patch is retested, the results take over the same URL as the old one.
In the meantime, here's one that failed only a couple days ago that might be worth looking at, and the patch needs work for other reasons so it's not too likely to be retested:
https://drupal.org/node/965078#comment-7500792
https://qa.drupal.org/pifr/test/537388
Comment #4
jthorson CreditAttribution: jthorson commentedFrom the quoted test:
The only real changes lately has been the apc_cli addition, and I do know that the D7 bots are throwing 'already loaded' APC errors, so there could be something there ... but I can't think of anything else at the moment.
Comment #5
David_Rothstein CreditAttribution: David_Rothstein commentedSince it looks like this will be hard to solve, I created #2319997: Don't automatically retest Drupal 7 core RTBC patches as a proposal for how to work around the problem.
Comment #6
dcam CreditAttribution: dcam commentedI can confirm that this can happen any time a patch is tested. I've seen patches fail the first time they're tested and their status is Needs review.
Comment #7
isntall CreditAttribution: isntall at Drupal Association commentedComment #8
jthorson CreditAttribution: jthorson commentedThis retesting is a PIFR thing. Neil disabled retesting of D7 patches a couple weeks ago.
Comment #9
David_Rothstein CreditAttribution: David_Rothstein commentedYou're probably thinking of #2319997: Don't automatically retest Drupal 7 core RTBC patches? It was just deployed today though, not a couple weeks ago.
That issue definitely helps make this one less of a problem, but it's a separate issue.
Comment #10
David_Rothstein CreditAttribution: David_Rothstein commentedLet's move this to the Drupal core issue queue for now, though. We don't know for sure it's an issue with the testbot (it could be, but it could also be caused by a bug in Simpletest that only triggers very rarely).
Also retitling this based on @dcam's comment in #6.