Best way to provide a copy of drupal.org for testing?

I'm afraid there is no perfect solution, the audience may be too diverse.

I'd personally probably go for suggestion 1.

But what about a drush_make file to pull all components/versions of the codebase together?
Although I understand that some parts are not publicly accessible (e.g. the bluecheese theme) this could come from an authenticated repo.

This would come as a suggestion 2a, or as an addition to 1 ;)

I started working on this tonight. I think eventually we may want something like what the redesign team used, which was a scrubbed DB and a bzr branch that pulled in the vendor branches of the required modules. In theory we may not even need a bzr branch as almost all the code will live in modules that are currently in CVS: VC API, VC Git, drupalorg, VC Project, etc, but having a bzr branch would probably make deploying tests sites with hudson much simpler, and they could be built the same way that the redesign branch was, which would allow continual integration as changes are made. I would hope that some members of the git team could be given access to at least check out from the bzr branch, merge in the vendor branches of VC API and related modules, and given access to scrubbed databases.

In the meantime, I've started updating the Drupal.org Testing profile for testing VC API and Git stuff. You can view the work at https://github.com/shomeya/drupalorg_testing. To get started with this, you can use drush make and the following command to setup all the modules for development:

curl https://github.com/shomeya/drupalorg_testing/raw/master/drupalorg_testing.cvs_deploy.make > do_git_testing.make && drush make do_git_testing.make do_git_testing

This will create a new Drupal installation in a directory labeled do_git_testing. You can add the --working-copy and it will make each module a checkout from it's respective version control source.

IMO, mikey_p's approach is going to be a perfect start for us. mikey_p, if you can perfect and package this we'll be in great shape.

I don't think we have to keep discussing the method.

@mikey_p: It took some debugging to get that profile installed :(

first:
Somehow the drupal_mail_wrapper() function did not get included, so I added a dummy version in the .profile file. This bit me in the end of the install, but that part was skippable.

After that, errors like:
"Failed to load Drupal user a -- node Drupal not saved." and several similar messages.

I figured that somehow the fist user 'a' was not created, hacking these instances to 'admin1' made it work.

After installing I get the occasional error from Beanstalkd complaining about the missing function drupal_queue_include(), which is not strange as that module requires Drupal_queue, which is not available.

Just my experiences... by lack of a better place to post them.

just an update to #5

Most problems are now fixed, see #977548: Create a 6.x-2.x branch with Git stuff.
But for the drupal_mail_wrapper() problem I now disabled the devel module in the install profile, which seems to somehow conflict with Aegir during the install.

I'm willing to look at options to support Aegir, but if it requires crazy hacks, than I think you're on your own. Please file any remaining issues over at drupalorg_testing.

I don't think we should *even* be considering anything regarding Aegir. This should be as simple and uncomplicated as possible. No extra stuff.

@rfay: I agree that there should be no dependency on Aegir, and there is none.

It's just that Aegir helps me and others to quickly deploy new drupal sites. I'm trying to iron out these issues to save myself time in future test sessions.

Let's close this issue, the initial question has been answered: Drupal.org Testing profile