PIFT/PIFT communication broken by D9 requeued patch [#2163683]

We had a requeued D9 patch today that broke all communication between d.o and qa.

https://drupal.org/comment/6357938#comment-6357938 was the culprit, an old patch, where the issue had been set to D9, but somebody did a retest on it.

The PIFR watchdog was "[0] => Error(s) found in file #30: [branch_identifier] not found in branch list."

On the d.o side, the pift #fail was Test queue request did not succeed: Denied - ensure that test master is enabled and/or has reporting on. full response. (full pift/d.o failed batch)

The key pift message I believe was Project release node [1859548] does not have a Drupal core API taxonomy term, which happened repeatedly during pift-cron. That node is the Drupal 9.x release node.

The Full batch report on qa.d.o shows the full details; the second main stanza is the branch list. Number 29 in the branch list (which is shown as #30 in the fail above; 0 vs 1 based...)

            [29] => Array
                (
                    [branch_identifier] => 1859548
                    [client_identifier] => 4274816
                    [file_url] => https://drupal.org/files/amd.patch
                    [link] => https://drupal.org/node/1542344
                )

WHen I was sure this was the issue, I did this on the d.o database:

select * from pift_test where id=4274816; (Note that the client_identifier from the PIFR side is the 'id' on the PIFT side.)
Then I deleted the test with delete from pift_test where test_id=317663;. Since it was already status 3 (failed) it seems it shouldn't have been here anyway,

select * from pift_test where id=4274816;
+---------+------+---------+--------+-------------------------------------------------------------+-------------+
| test_id | type | id      | status | message                                                     | last_tested |
+---------+------+---------+--------+-------------------------------------------------------------+-------------+
|  317663 |    2 | 4274816 |      3 | FAILED: [[SimpleTest]]: [MySQL] Drupal installation failed. |  1345159216 |
+---------+------+---------+--------+-------------------------------------------------------------+-------------+

That solved the problem.

Comment	File	Size	Author
#9	2163683.diff	1.89 KB	drumm

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

jthorson CreditAttribution: jthorson commented 27 December 2013 at 23:54

I suspect the batch building logicd doesn't filter out D9 tests, but the core compatibility variable doesn't include the 9.x vocabulary term id. Adding that term id may solve the issue (though obviously there is a logic flaw in the code which should be fixed too. )

Comment #2

drumm

he/him

NY, US

CreditAttribution: drumm commented 16 May 2014 at 15:51

Parent issue:

» #2170443: [meta] Create a plan for implementing semantic versioning for core

Comment #3

catch

he/him

English

CreditAttribution: catch commented 19 May 2014 at 11:38

I think this is because the 9.x version was hacked in without a branch/tag.

Comment #4

drumm

he/him

NY, US

CreditAttribution: drumm commented 19 May 2014 at 23:33

9.x isn't actually hacked, it exists: http://drupalcode.org/project/drupal.git/tree/refs/heads/9.x and https://drupal.org/node/1859548

drush vget pift_core
pift_core: Array
(
    [87] => 87
    [103] => 103
    [7234] => 7234
)

Those are the API compatibility terms for 6.x, 7.x, and 8.x. Adding in 9.x would be on the way to fixing this, but isn't a good general solution. Ideally, we could remove taxonomy from this completely, the API compatibility term isn't fun to code around, but may be needed in some form for now.

Comment #5

drumm

he/him

NY, US

CreditAttribution: drumm commented 19 May 2014 at 23:37

Or, simply adding 9.x may be a good solution for now, since project_issue_file_test is being replaced by drupalci_drupalorg.

Comment #6

jthorson CreditAttribution: jthorson commented 20 May 2014 at 04:45

Adding in 9.x to the api terms would probably fix this entirely; but I'm not sure what other implications that might have elsewhere.

Next week is a 'free evenings' week; I'm hoping to be able to visit this then, and maybe even develop a patch ... but make it a general policy to not deploy new testbot code the week before a major con. ;)

Comment #7

drumm

he/him

NY, US

CreditAttribution: drumm commented 25 June 2014 at 22:58

Assigned:

Unassigned

» drumm

Taking this, I'll add 9.x to pift_core after a bit of research.

Comment #8

drumm

he/him

NY, US

CreditAttribution: drumm commented 25 June 2014 at 23:15

pift_compatibility_list() checks API terms for field_release_recommended, so just adding isn't a good solution. I think #2011210: Validate individual tests instead of whole batch during d.o <-> qa.d.o communications could be the root cause, or at least a common way for problems to not become big problems.

Comment #9

drumm

he/him

NY, US

CreditAttribution: drumm commented 26 June 2014 at 00:25

Status:

Active

» Needs review

File	Size
2163683.diff	1.89 KB

I decided to prevent patches in unsupported API versions from being included in the batch. This will persistently leave unsupported files in "Queued for testing." Any support requests should change from "is all testing halted" to "why isn't this one stuck in the queue."

If we were continuing with PIFR/T, I would want to remove testing-related UI from unsupported branches. However, this is okay to leave broken.

Comment #10

drumm

he/him

NY, US

CreditAttribution: drumm commented 26 June 2014 at 00:30

I think this specific issue can be removed as a blocker for #2170443: [meta] Create a plan for implementing semantic versioning for core. Semantic versioning will not create more "core API compatibility" terms, everything will still be lumped under 8.x. If needed, a separate issue can make sure files get tested against the most current of 8.0.x and 8.1.x, or even multiple versions.