Add deployment scripts for Drupal Forge

@darren oh can you please explain in a bit more detail whats the blocker and whats required to get around the dind issue?

The blocker for Docker-in-Docker is that it requires at least 8G of memory and we can only afford cheap hosting. To get around that we would need a version of DDEV that can manage other containers in a cluster. The version of DDEV we have now was originally called DDEV Local and has to run on the machine that hosts the containers. There was a companion product called DDEV Cloud acquired by Platform.sh that might serve our needs if Platform.sh allows us to use it.

Thanks for working on this important project!

I'm trying this out. Some nits in the presentation: The grammar and usage can be improved.

"This can take up a few minutes" -> "This can take a few minutes"

"Access to DevPanel to work more Powerful" -> (Rethink this to say what you want. It's not meaningful currently in normal English usage). Maybe "Use DevPanel to empower your work" or "DevPanel helps power your work" ?

* The build of this took a really, really long time and it didn't give any idea of how it was progressing or when it might complete. I gave up after waiting 15 minutes, but will leave the tab open to see if it ever completes. (https://dev.drupalforge.org/drupalpod/3dde90ea-f4e2-4e39-9b6d-7fa13f1d43bf)
* Since I haven't seen it yet... Is there a way to configure PHP version or related configuration?

Hi Randy, thanks for checking it out. Your feedback is appreciated. The configuration is determined by URL parameters.

The build completed after 20-25 minutes.

I see it's PHP 8.3, and `composer install` worked.

`composer require drush/drush` never seemed to return, no output given. I guess this is just amazingly slow.

I also tried `time composer require drupal/search_api_solr` to see what would happen and if it would be usable after that. It took 6 minutes.

I tried to log into the application, but was unable to, not knowing the username (or maybe the password?)

`composer require drush/drush` got me able to do a `drush uli`, but it took 5:40 to complete

Having two separate UIs (the application and the VS Code) is a little complex, but I would think people could learn how to navigate it.

Right now, it's the overall performance that makes this way too hard to use.

@darren I don't see any option in the extension UI to choose a PHP version, and since it can't be changed other ways, it's a bit complex. I would certainly think people would expect that capability.

The git version I checked out is not what I expect, I asked for 11.x, but I get drupalforge instead. It's really unclear what I should be doing to look at the MR I checked out.

Oh, I see drupal is installed in repos/drupal, as it was in Drupalpod. I always hoped that would get fixed and be more obvious, it's too bad that it has landed here :(

The suggestion in Drupalpod was that the drupal code might land in /workspace/drupal and the VS Code interface be opened there by default. Maybe you'll be able to do something like that.

We found out the DevPanel developers were giving us under-powered containers. This has been fixed and it spun up in 4 minutes in my last test. I'm planning to build an optimized image to reduce launch time further. I appreciate the suggestions for improvement. I’m thinking to keep review for this issue manageable we should make the fewest possible changes to DrupalPod itself until after this is merged in.

Thanks, I'll give it another go when you say it's ready.

I did some testing and found it worked well. It took about 6 minutes to spin up, which is pretty good going. I like the way it gives you a control panel that lets you launch the site and the VSCode environment separately. I found the tiny site window in the corner of the old DrupalPod less useful.

I haven't tried pushing to a repo yet. I'll try that and post when I do.

I tried again this morning. Waited 25 minutes for the build before moving on to something else. https://dev.drupalforge.org/drupalpod/bcec9fb8-ef6b-4dcc-984e-9c4d23d09662

I think the goal should be <2-3 minutes to be useful.

When it completed, I got an untrusted URL for the VS Code interface at https://cs-dev-306b2ae7-80a772f5-aft17lcv.cms-devpanel.click/

The cert was issued to `localhost`, not to *devpanel.click.

Your connection is not private
Attackers might be trying to steal your information from cs-dev-306b2ae7-80a772f5-aft17lcv.cms-devpanel.click (for example, passwords, messages, or credit cards). Learn more about this warning
net::ERR_CERT_AUTHORITY_INVALID
Subject: localhost

Issuer: localhost

Expires on: Jan 18, 2038

Current date: Mar 10, 2025

PEM encoded chain:
-----BEGIN CERTIFICATE-----
MIICNzCCAd2gAwIBAgIRAOOlAFcVJt3VNDllSx6THDEwCgYIKoZIzj0EAwIwdTEL
MAkGA1UEBhMCVVMxEzARBgNVBAgMCkNhbGlmb3JuaWExFjAUBgNVBAcMDVNhbiBG
cmFuY2lzY28xDTALBgNVBAoMBEtvbmcxFjAUBgNVBAsMDUlUIERlcGFydG1lbnQx
EjAQBgNVBAMMCWxvY2FsaG9zdDAeFw0yNTAyMTgxMzMyMTFaFw0zODAxMTkwMzE0
MDhaMHUxCzAJBgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRYwFAYDVQQH
DA1TYW4gRnJhbmNpc2NvMQ0wCwYDVQQKDARLb25nMRYwFAYDVQQLDA1JVCBEZXBh
cnRtZW50MRIwEAYDVQQDDAlsb2NhbGhvc3QwWTATBgcqhkjOPQIBBggqhkjOPQMB
BwNCAAQiE6cjCQcKa68YCAfbPtQnm1mCaQZaY8+6Efom3/0zTkwzVrbu09BPQjn0
T4I/ehSkLZN7mpOeCZvk2ovlf/wXo04wTDAMBgNVHRMBAf8EAjAAMB0GA1UdJQQW
MBQGCCsGAQUFBwMBBggrBgEFBQcDAjAdBgNVHQ4EFgQUpDjlZngv5rZGPUElbikL
pKPQMTEwCgYIKoZIzj0EAwIDSAAwRQIhALNrzY6ooNfEkXIiEQNg1hus8i43YzRH
RZhSblU7kfGYAiAs6NzbzHvUM37ZRHlslOVja2pioONHMwTbVREAX/eGcA==
-----END CERTIFICATE-----

`time composer update --with-all-dependencies` (with no changes to the composer config) took 1m20s.

By using this website, you warrant on behalf of yourself, your users, and other parties you represent that you will not:

Modify, copy, prepare derivative works of, decompile, or reverse engineer any materials and software contained on this website;

I am going to assume that merging DevPanel related functionality will not make DrupalPod a derivative work of DevPanel.

Was going through the instructions at https://www.drupal.org/docs/develop/development-tools/drupalpod/drupalpo... → and am curious why drupalforge uses https instead of ssh to checkout the forks? It would be much simpler with a single ssh key instead of having to enter the username and password... This is how drupalpod was set up and once you have your ssh keys set up in gitlab, it's a much smoother process.

additionally, application keys expire.. wu tang is forever..

in this instance 'wu tang' === 'ssh keys'