[wp-trac] [WordPress Trac] #57896: Improve devcontainer + Codespaces support

[WordPress Trac]

#57896: Improve devcontainer + Codespaces support
------------------------------+-----------------------------
 Reporter:  SergeyBiryukov    |       Owner:  (none)
     Type:  enhancement       |      Status:  new
 Priority:  normal            |   Milestone:  Future Release
Component:  Build/Test Tools  |     Version:
 Severity:  normal            |  Resolution:
 Keywords:                    |     Focuses:
------------------------------+-----------------------------

Comment (by rmccue):

 @helen, @mdawaffe, @jeremyfelt and I all worked on Codespaces support a
 bit during WCUS contributor day, and there were a few key issues we noted
 in addition to the aforementioned ones:

 1. The WordPress version inside the container is latest stable, ''not''
 the version from the repo. This is due to using the "official"
 [https://hub.docker.com/_/wordpress WordPress Docker container], which
 bundles its own copy of WordPress.
 2. Opening the URL causes a redirect to `https://...-443.app.github.dev/`
 3. Using `docker ps` or `docker logs` doesn't show the running containers

 We didn't fully debug it during contributor day due to the terrible wifi,
 but I picked it back up today and sorted a few of these. Namely:

 1. Mounting `../src:/var/www/html` will override the WP version with the
 version in `src/`, fixing this issue
 2. Setting `$_SERVER['HTTP_HOST'] = $_SERVER['HTTP_X_FORWARDED_HOST']`
 will fix this issue (copied from [https://github.com/humanmade/altis-
 local-
 server/blob/cdf079c0ff24a54bf7e2a5c125e1e2b866dbd5f4/inc/namespace.php#L100-L107
 the Codespaces setup on Altis])
 3. The Codespace is incorrectly configured to use docker-in-docker. This
 allows you to run your own containers, but can't connect to the current
 ones, as the devcontainer terminal connects to the container specified in
 `"service"`, i.e. `app`. (This is new config I'd not seen before.)
 Switching to use docker-outside-of-docker instead handles mounting the
 Docker binds correctly, and allows you to view running containers and logs
 properly.

 I'll PR this patch soon.

 @mdawaffe I think the behaviour you were seeing with `docker-compose cli
 ...` working was because it was starting a '''new''' CLI service.

 I also tried switching over to use the main docker-compose we already
 have, but that causes errors for some reason - it's very hard to see in
 the build logs exactly why that happens.

 Additionally, the `cd` in the `setup.sh` appears to be useless - `pwd` is
 already `/workspaces/wordpress-develop` anyway.

 A few other things I think we should aim to improve:
 - Since we're using the `wordpress` container rather than our own, it's
 ''also'' not a devcontainer-specific container - some tools like npm are
 hence out-of-date. It may be worth making our own for this specific
 reason, even if we can't switch to using the base `docker-compose.yml`
 config.
 - The default username and password (admin/password) isn't displayed
 within the terminal. We could display both this and the mapped URL for
 ease-of-use
 - Installing Chromium is slowwww due to the vast number of dependencies.
 We should look to either incorporate it into a prebuild or make it an
 optional follow-up, imo
 - The postCreateCommand log is useless - you need to pop open the full
 creation log to actually see the Webpack build log
 - We should consider preloading some PHP extensions, perhaps by adding the
 [https://github.com/devcontainers/features/tree/main/src/php `php`
 feature] (although this also installs PHP, which isn't that useful)

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/57896#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform