Add DevPanel support for Drupal Forge

Before we do this, let's get validation from the product owner that we want to spend the time/effort. We need to carefully choose which platforms we support, because there are a lot and we can't support 'em all.

I'm hesitant about this. We have infrastructure set up to contribute and it is based on DDEV. That's our officially supported platform for making changes to Drupal CMS. This is all documented at https://git.drupalcode.org/project/drupal_cms/-/wikis/Contributing-to-Dr....

If the documentation is incomplete, then we can certainly update it to make it more useful. It's not really official documentation anyway, but it's better than nothing.

If @pameeela and @tim.plunkett feel it's worthwhile to support an additional platform for contributors, then I don't think I have any particular objection to going along with this (at least, not with the amount of information I have). But it's really up to them.

To be honest, I had not heard of Drupal Forge before this request, so I have looked into it and I can see that it is a tool for launching temporary Drupal sites.

I tried the Drupal CMS launch and have a few concerns:

1. It bypasses the installer, and I understand why, but this means the onboarding pages are skipped and that's a key part of the experience.
2. The version of Drupal CMS that I'm seeing after installing is at least two months old, which I can tell because it still has Gin's high contrast mode enabled, and that was updated on Aug 27. This makes it problematic to promote as a way to contribute, not sure if I am missing something there?

I don't want to discourage this effort at all, but I do think that based on the vision presented on the Drupal Forge product page → , we are in an awkward position if we add support for this now. We already have the WASM trial which is the "official" trial experience, and the DA is working on the "move your trial to hosting" side of things. So I think we need to wait and see how that plays out before we look at adding support for specific platforms.

We will provide updates on that process as it develops, it is still just an idea really!

I agree with your concerns. They are due to Drupal Forge having to rely on a fork that gets outdated. The purpose of this issue is to get Drupal Forge to launch code directly from the Drupal CMS project repository instead of from a fork so that contributors can use it effectively. Our process for moving trial sites to hosting will be coordinated with the DA, so it is not a competing effort.

darren oh → changed the visibility of the branch test-ddev to hidden.

darren oh → changed the visibility of the branch main to hidden.

darren oh → changed the visibility of the branch develop to hidden.

darren oh → changed the visibility of the branch 0.x to hidden.

I have tried the www.drupalforge.org offerings over the last few months. It is a great way to test and build on Drupal 11, Drupal 10, and also DrupalCMS as well as BackdropCMS. Now that the drupalforge template is using the latest DrupalCMS repo I think it is a good idea to consider extending the DrupalCMS repo this way beyond just a ddev approach. This may also serve as an example of how the DrupalCMS repo may be extended for other environments such as lando. I support revisiting this.

If this is going to happen, it will in all likelihood be part of the trial experience.

I am not actually convinced that we need to merge this in order for it to work.

Here's what to do: download the development snapshot from https://git.drupalcode.org/api/v4/projects/157093/jobs/artifacts/0.x/raw... (this is continually updated but the URL stays the same). Extract the zip file, and put the .devpanel directory into it at the project root. Deploy to DrupalForge. Done!

You'll want to remove this kind of stuff from .devpanel, though:

cd $APP_ROOT
sudo rm -rf lost+found
jq -s ".[0] * .[1] * .[2]" project_template/composer.json dev.composer.json components.composer.json > composer.json
composer install
ln -s -f $(realpath -s --relative-to=$DDEV_DOCROOT/profiles project_template/$DDEV_DOCROOT/profiles/drupal_cms_installer) $DDEV_DOCROOT/profiles
test -d node_modules || npm clean-install --foreground-scripts

Is there any reason that won't work? The zip file contains an actual snapshot of a real Drupal CMS project that you could actually use, whereas our git repo is not meant for that purpose and should not contain a .devpanel directory.

If we don't check out the code with Git Drupal Forge cannot provide a ready-made dev environment for contribution.

Well...I know this is stretching it, but what if we had a GitLab webhook that pinged a service on your end when a build completes? Then you could automatically download and alter the zip file, turn into a small git repo, and check it out.

But either way, I don't want to commit .devpanel to the top level of this repo, precisely because this repo is not meant for DrupalForge's purposes. If we're going to have a .devpanel directory, it needs to go in a build which gets spun up based on what's in project_template.

As the Drupal Forge project leader, I am confused by the assertion that this repo is not meant for Drupal Forge's purposes. I started Drupal Forge to provide sustainable support for this repo.

The git repository is a monorepo that gets subtree split into multiple smaller projects for distribution (see https://git.drupalcode.org/project/drupal_cms/-/wikis/Architecture-Decis...). It has a unique structure and infrastructure. It does not represent what an actual Drupal CMS project (i.e., a site built with Drupal CMS) would be. The zip file does.

I would expect people who want to start a site of their own to use DrupalForge. So if .devpanel was added, it would need to be added to project_template (or to a zip file which is built from it).

If someone wants to contribute to Drupal CMS, DDEV is our official platform for that. They would use this repo's existing DDEV support, and this repo, to do it. DrupalForge would not be an officially supported tool for that (which isn't to say it couldn't be made to work, but we don't really want to commit support for non-officially-supported contribution platforms).

darren oh → closed merge request !142