Scenario:

Test: http://qa.drupal.org/pifr/test/160244

- Project used to have an empty 'relations_test.module' file, which was removed several weeks ago.
- New commits cause a 'requeue' for the existing test array.
- Because the file scan for .module files originally found relations_test.module, the $test array contains two module entries: 'relations_test' and 'relations'.
- Requeue pulls the existing (old) $test array from the PIFR database
- Branch test fails on syntax due to the 'missing' relations_test module.

Having a button inside the 'tools' area on qa.d.o, with the option to re-create the $test array and update the database, would allow resolution of issues like this without needing to manipulate the database directly.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

seandunaway’s picture

rfay fixed this with the following:

rfay: mysql> delete from project_info_module where module_id=465766;
rfay: Query OK, 1 row affected (0.00 sec)

After a dummy commit to the project the test array was rebuilt.

The UI element to do similar could be helpful!

seandunaway’s picture

Which module/repo is providing the tools links? I don't have permission to see them on qa but maybe I can take a stab at the UI addition locally? I can't find much on QA infrastructure.

rfay’s picture

@rump if you create an account on qa, I'll give you privs to see that stuff.

jthorson’s picture

It's in pifr_server ... the pifr_server_test_tools_form function inside pifr_server.test.inc.

However, the project_info_module table isn't provide by PIFR ... it's provided by PIFT, and exists on d.o while PIFR runs on q.d.o.

That said, I believe a similar query in the pifr_branch table may have the same effect:

delete from pifr_branch where client_identifier = [project release nid]

seandunaway’s picture

@rfay: thank you. i just registered for an account pending approval.

@jthorson, thanks! i'll take a look.

seandunaway’s picture

Are scratch sites available for qa.d.o? or should I submit for the bzr access?

I'm having a less than stellar time trying to duplicate this environment locally.

rfay’s picture

@rump I'll be happy to help you get going. QA is not set up for scratch sites, but it's not hard at all to get going with it. http://drupal.org/automated-testing has an inadequate section on setting up a dev environment; I'd love to have you improve it as you learn.

Setting up a personal testbot is really easy. And really, a qa site is pretty easy. Getting a d.o clone is a bit more work. But we're here to help.

I do recommend applying for bzr/ssh access as soon as possible.

Again, please let me know how I can help.

jthorson’s picture

Tasks:
1. Add 'rebuild' local task to menus at pifr/test/%testid/tools.
2. Use same access permissions as the 're-test' task at the same location
3. Content is a form with 'Remove cached $test array from database (i.e. Force rebuild)' and a 'Clear test entry' button
4. Form submission performs a "delete from pifr_branch where test_id = $test_id" query, where test_id is available from the url argument.
5. Form should pass through a confirm form to ensure it's not susceptible to CSRF attacks.

Caveat:
I think that deleting the pifr_branch table entry is sufficient to trigger a rebuild ... but this assumption has not been validated/tested.

jthorson’s picture

Status: Active » Needs review
FileSize
1.54 KB

This should make it a little easier to deal with issues such as #1144472: Entity API tests try to enable a not existing module and fail ...

jthorson’s picture

Status: Needs review » Postponed

Above patch causes major issues with the PIFT/PIFR communication ... seems to work okay for patch tests, but it throws branch tests into a loop. Branch tests can be fixed by doing a pifr_server_branch_delete($form_state['values']['test_id']) for branch tests, instead of the test_delete() in the above patch.

However, even with this ... it does not address the issue for the linked Entity API test, since the missing module is passed along to PIFR in the batch ... not pulled from the PIFR side as I (wrongly) described in the issue.

As a result, I don't think we need this ... instead, we need to add this functionality to PIFT, so that it creates the batches properly.