Allow automatic retests for contrib modules chasing HEAD

I certainly support this. When Examples chased HEAD in 7.x, it would have made all the difference.

This is something I have wanted to do for a while, but after talking with jthorson seems like we are game to implement a views specific hack in favor of waiting for new system rewrite to do this nicely.

Yeah, I think adding a 'views-specific' hack to the PIFT code to allow it to be retested along with D8 HEAD may be a valid (and temporary) solution. While this approach is butt-ugly, the 'proper' approach would include a fair bit of new feature development, UI development, and new database tables/columns ... which is a bit more than we'd like to take on given the desire to focus our efforts on the next generation of conduit/worker code instead.

In addition, we'd like to cap new 'feature' development of PIFT/PIFR to help ensure consistency and stability in the testing infrastructure as we approach the D8 code freeze (and push to D8 release).

If noone is against the hack approach, all we would require is logic inside of the pift_cron code which states "If commit belongs to D8, also requeue test_id ".

A non-hack would be better, but could we at least make it handle an array of test ids?

what we were talking about what completely hard coding, no interface no nothing, a single condition and one line to queue the test, anything more begs where we stop before completing the feature. If we have a set of contrib projects we want to enable this for perhaps we can be a variable that contains the list and put on settings page, but that is as far as I would go before we build it out in new version.

Code speaks. :)

Here's what I was referring to as a temporary hack.

+++ b/pift.moduleundefined
@@ -280,6 +280,15 @@ function pift_versioncontrol_code_arrival(VersioncontrolRepository $repository,
+            $queue_with_head = array(273938);

If we think we have a usecase we can make that a variable_get(), but otherwise this is good with me.

Needs testing, which is always the fun part with this stuff.

Drupal variables as arrays work fine, and drush can set them.

I like that much better!

Committed (to allow testing) to 6.x-2.x.

Commit ID c7c1fda.

BTW, http://drupal.org/node/664452#comment-5078776 explains the format for using drush to set an array variable. I'm not sure, but we may need drush 5 for it.

For setting non-scalar values yes you need drush 5.

Rolled a 6.x-2.10-alpha1 release and deployed on drupal.org. Had webchick push a D8 commit, which resulted in both D8 and Views being queued; so initial testing was successful.

Will leave the 6.x-2.10-alpha1 release running on d.o for a couple days to look for any unforeseen issues which might spill out of this ... then can look at making it a 'final' 2.10 release to ease any minds which would prefer not having something tagged 'alpha' on d.o. :)

Just a note ... now that Views is in Drupal core, I deleted the pift_requeue_with_head variable on drupal.org to prevent the views test from being queued alongside of core.

I've also reverted the code change that checked this variable in the 6.x-2.x codbase, since it was not also present in 7.x-2.x ... re-opening for discussion as to whether it is worthwhile leaving this in the code to accommodate potential future requirements.