Failed patch test does not set issue status to "Needs work"
» Both failed or succesful patch test does not set issue status to "Needs work"
I create 4 patches during Monday 2011-03-01 (3 successed, 1 failed) for Drupal 7 core and no one from them set the status. Plus test details are still same in the issue queue ("Test request sent"), but the tests were processed 3 days ago:
I'm going to leave this as active right now, because I've made no changes that would have a reason to fix this. Reports of good or bad behavior are appreciated.
Thanks for the report. The problem here was that Plugin Manager 6.x had not tested clean - it just needed a retest. I retested it and now the patch also comes clean. The actual problem that you had was #961172: All D6 Core patches are failing.
Without any help, you could figure out what was going on by clicking the "view test" link, seeing it wasn't being tested, and following that to the test for your branch. And you'd see it not having been tested...
The easiest way to fix it was to resubmit the test on qa. That requires somebody with an account there.
The second-easiest way would have been a dummy commit, which would have forced a test of the branch.
Comments
Comment #1
rfayThis was a duplicate of #1061710: Cron run emits "WD pift: Failed to retrieve test results from to server: Parse error.[error]"
Comment #2
rfayNo, I was wrong. This doesn't set the issue status correctly.
Comment #3
wojtha commentedI create 4 patches during Monday 2011-03-01 (3 successed, 1 failed) for Drupal 7 core and no one from them set the status. Plus test details are still same in the issue queue ("Test request sent"), but the tests were processed 3 days ago:
Issues and tests:
#364348-19: OpenID throws an error when two accounts try to use the same OpenID (test: http://qa.drupal.org/pifr/test/130354) success
#575810-4: OpenID discovery spec violation - follow redirects. (test: http://qa.drupal.org/pifr/test/130349) success
#1076366-4: OpenID discovery spec violation - fragments are removed from claimed id (test: http://qa.drupal.org/pifr/test/130374) failed
#1076414-1: Openid discovery - OpenID v1 OP service with lower priority is chosen instead OpenID v2 Claimed id service (test: http://qa.drupal.org/pifr/test/130369) success
All patches were against Drupal core v7 / HEAD
Comment #4
wojtha commentedIt seems it is not specific to patches against Drupal 7. I Found this one for Drupal 6 from February 28, 2011 at 3:40pm:
#453400-22: "-wrapper" HTML ID not output for #type checkboxes/radios test: http://qa.drupal.org/pifr/test/130324 failed
Comment #5
berdirSubscribing.
Same behavior as I reported to rfay in #irc, the test information widget doesn't update at all, it's not just the missing needs work status change.
Comment #6
wojtha commentedIt seems it is working now... I think we can close this ...
Comment #7
rfayI'm going to leave this as active right now, because I've made no changes that would have a reason to fix this. Reports of good or bad behavior are appreciated.
Comment #8
DrewMathers commented#832464-4: Core update listed "Test request sent" since 8-Apr-2011
#1059990-1: Patch format for Drupal.org is going to change to -p1 since 13-Feb-2011
#1059990-7: Patch format for Drupal.org is going to change to -p1 since 13-Feb-2011
#1059990-9: Patch format for Drupal.org is going to change to -p1 since 18-Feb-2011
Comment #9
rfayThanks for the report. The problem here was that Plugin Manager 6.x had not tested clean - it just needed a retest. I retested it and now the patch also comes clean. The actual problem that you had was #961172: All D6 Core patches are failing.
Comment #10
DrewMathers commented@rfay, thanks. Is this something I could have done myself as a non-maintainer, or did it require a project maintainer or someone from the QA team?
Comment #11
rfayWithout any help, you could figure out what was going on by clicking the "view test" link, seeing it wasn't being tested, and following that to the test for your branch. And you'd see it not having been tested...
The easiest way to fix it was to resubmit the test on qa. That requires somebody with an account there.
The second-easiest way would have been a dummy commit, which would have forced a test of the branch.
Comment #12
jthorson commentedTriaging. We have duplicates of this in d7qa for the post-migration version of this symptom.