Log of recent 'automated project application reviews' IRC chat
EDIT: I'll have to come back and fix the IRC tags. :(
ELC: The automated coder stuff stalled on mods needed for project_issue.
jthorson: :/ As in no one will commit them, or they haven't been written?
There's no code for drupalorg_projectapps yet ... which is why you can't find a sandbox. :p
Haven't been written. I ran into one dead end after another. The latest was that sandbox project issue queues don't have a 'version' field, so there's no way of telling the testing infrastructure what version of code to test.
I discussed this with dww at BADCamp, and the suggested way forward was to modify project_issue to use string versions instead of release nodes for that dropdown (since sandboxes have no releases, the existing dropdown won't work).
hmm.. commit hash might have to be brought in
branch + hash
There's enough info in the db already ... the versioncontrol_labels table does include strings and an associated unique label_id for every project (sandbox included).
I wonder how much effort it would be to duplicate d.o on a local test server .. don't suppose there's a limtied backup :P
Dww pointed me towards a solution for that ... one sec.
ah, well if they're in there already it should just be a case of changing every reference to it .... urgh
Changing every reference won't really work ... everything in project and the testing infrastructure assumes releases. :(
yeah well, those would be the reference to change ;) sounds like replacing a LOT of code
But ... changing just the project_issue dropdown box to a 'version string' from that table, instead of based on release nodes ... and then, if a release node exists, adding both the string and the release node to the $node['project_info'] array ... would allow us to build a project-app trigger that uses the string.
which would be awesome
Also required: add a new column to PIFT to store the label_id in addition to release node id ... that, I have code for.
However ... because I started to burn out on multiple roadblocks ... I backed off to look at other alternatives ...
And I think there might be an easier option ... adding a new dedicated test type to the testing infrastructure, just for project apps, and having all tests of that type sent to a new PIFR plugin that runs Klausi's script.
... also a lot of code.
Looks like installing a local d.o copy is a multi-day process in itself .. still have to get a testbot to tie onto it as well
Project_issue ticket is at http://drupal.org/node/1328928 ... my other notes are all at http://drupal.org/node/1253890
http://drupal.org/node/1328928 => Refactor version selection box to leverage "version strings" instead of "release strings" => Project issue tracking, Issues, normal, active, 0 comments, 2 IRC mentions
http://drupal.org/node/1253890 => Conversion notes, impacts, and strategies => Refactor PIFR/PIFT unique branch identifier, Code, normal, active, 21 comments, 8 IRC mentions
The 'new approach' isn't documented yet.
Another option, which folks didn't really seem to like, was to attempt to parse a version string out of a patch filename.
Hacky, I know ... but until the project_issue changes, it was my last-ditch alternative.
filenames are never done correctly though
This would be adding the option to the existing ... if one found, use that version ... if not, fall back to today's methods.
So what we need is: i) someone to patch project_issue to use version string instead of release_nid, and store both values in the issue node (instead of just the release_nid, today), ii) Patch to add the version drop-down to sandbox project issue queues, and iii) Add a column to PIFT to store the label_id that sandboxes can key off of instead of release nids (about 80% done).
*** timplunkett is now known as timplunkettAFK
Alternatively, need someone to i) create a new PIFR_Projectapp plugin for the testbots, ii) Modify PIFT to add a new test type, and iii) build some sort of form for selecting the branch and triggering a new project-app test via PIFT, via a new drupalorg-projectapps module.
As for test environments ... you may be better off going with http://drupal.org/node/1018084 than locally. Unfortunately, we only have one qa.d.o dev environment that we've been sharing.
http://drupal.org/node/1018084 => Develop on our server (preferred) => 0 comments, 37 IRC mentions