Any project/any branch (including sandbox) should be able to have automated testing [#1123896]

It's pretty important to have automated testing for any project. Consider the new core initiatives. Obviously they have to be tested during incubation.

But currently we could never test sandboxes because the VCS ID id determined from project release node, etc. It's quite tied up with project release nodes.

We should make it possible to test *any* branch of *any* project.

Comments

Comment #1

rfay

English

Palisade, CO, USA

CreditAttribution: rfay commented 11 April 2011 at 19:13

IRC conversation with sdboyer quoted here:

<sdboyer> any way the testing infra could shift over to looking at the vcapi data directly?
<sdboyer> oughtn't be
<Crell> Hm.  OK, yeah, that really really sucks for initiative owners...
<rfay> sdboyer, I would assume there's a way
<sdboyer> just use the serial ids
<sdboyer> those are agnostic
<sdboyer> and you get agnostic objects back from VersioncontrolRepository::load{Tags,Branches}()
<rfay> sdboyer, I didn't understand that statement at all :-)
<sdboyer> err, you get backend-specific objects, but the interface is agnostic
<rfay> What is a serial ID?
<rfay> What does it come from? 
<rfay> How does a patch know what branch it's for?
<rfay> Things like that. But not now.
<sdboyer> branches & tags ("labels" collectively, in versioncontorl parlance) are represented in the {versioncontrol_labels} table
<Crell> rfay: It's how you determine if you are using Frosted Flakes or Cheerios.
<sdboyer> too late :)
<sdboyer> that's provided by versioncontrol api itself
<rfay> Crell, it's not so disastrous. Full release is OK
<sdboyer> {project_release_nodes} joins to that table through {versioncontrol_release_labels}
<rfay> Really it's only PIFT that understands release nodes. And that is really just a relic of the past.
<rfay> So there probably is hope here.
<sdboyer> ok cool

Comment #2

rfay

English

Palisade, CO, USA

CreditAttribution: rfay commented 11 April 2011 at 19:14

Title:

Any project (including sandbox) should be able to have automated testing

» Any project/any branch (including sandbox) should be able to have automated testing

Comment #3

forestmars CreditAttribution: forestmars commented 2 May 2011 at 03:47

Are there any related issue queues for this, and/or any new developments?

Comment #4

rfay

English

Palisade, CO, USA

CreditAttribution: rfay commented 2 May 2011 at 04:03

There are no plans. Do you have a non-project that you want to be tested? If you have a full project, it can be tested.

Comment #5

jthorson CreditAttribution: jthorson commented 24 August 2011 at 15:18

Status:

Active

» Needs work

Refactored the code to use vcs label_id instead of branch release_nid. See the database migration changes & patch in http://drupal.org/node/1253890 .

Needs some more work (integration with project_dependency) to prevent it doing full drupal tests for contrib branches. Project_dependency will allow the population of the 'drupal.modules' argument, which will solve the 'full drupal test' issue.

Code also needs some overall cleanup (could add some efficiencies, remove original commented code and development comments), as well as the project_dependency integration ... but after that, it's close.

I've successfully ran two branch tests on rfay.redesign / qa.scratch before reverting the sites back to their original state ... could use additional testing on issue queue patch triggers and commit triggers to make sure it's all working.