[wp-trac] [WordPress Trac] #57187: Add devcontainer + Codespaces support

Thu Feb 9 03:19:58 UTC 2023

#57187: Add devcontainer + Codespaces support
------------------------------+---------------------
 Reporter:  helen             |       Owner:  (none)
     Type:  enhancement       |      Status:  new
 Priority:  normal            |   Milestone:  6.2
Component:  Build/Test Tools  |     Version:
 Severity:  normal            |  Resolution:
 Keywords:  has-patch         |     Focuses:
------------------------------+---------------------
Changes (by helen):

 * milestone:  Awaiting Review => 6.2

Old description:

> Finally opening up a Trac ticket after posting on
> [https://make.wordpress.org/core/2022/11/09/improving-the-contributor-
> experience-github-codespaces-for-wordpress-core/ Make/Core] :)
>
> I'd like to start adding "official" support for remote dev environments
> to contribute to core (including testing) - I believe this makes
> contributions more accessible to a wider audience, by making fully-
> featured dev environments available on more devices and getting people
> started much faster (i.e. you click a button on a repo instead of braving
> conference wifi to download Docker images or passing around USB sticks).
>
> This ticket is more specifically for devcontainer + Codespaces support in
> core so you can start a Codespace from GitHub web - devcontainers are a
> set of config files that can be used with local Docker as well via VSCode
> (and otherwise). Codespaces is a GitHub-hosted solution to then run those
> devcontainers in the cloud (Azure) with the default ability to open
> VSCode for the Web connected to said container for a completely in-
> browser experience, meaning you can have a fully-featured code editing,
> building, and app running experience on a tablet.
>
> Here's what I think is needed but need opinions on where we should have
> boundaries between published images, devcontainers, and setup scripts as
> I am not myself particularly knowledgeable about containers 😁
>
> * A baseline image that can be used for any number of dev needs - core,
> Gutenberg, other plugins and themes, testing, etc. This should probably
> include Composer, the appropriate Node+npm versions, and wp-cli. I have
> never yet gotten Xdebug to work in Codespaces. My current PR uses the
> Docker-published `wordpress` image, not the ones we use for `wp-env` -
> seems to me it would be nice to have something that spins up faster but I
> don't know enough here.
> * A `devcontainer.json` that includes some VSCode extensions (or
> explicitly decide not to include any).
> * Documentation, esp in the Make/Core Handbook. :)
>
> Full disclosure: I do currently work at GitHub; not in this area, but I
> do have access to helpful resources as needed. There are a number of
> services out there for remote dev with varying tiers of free usage, over
> time it would be great to support multiple options.

New description:

 Finally opening up a Trac ticket after posting on
 [https://make.wordpress.org/core/2022/11/09/improving-the-contributor-
 experience-github-codespaces-for-wordpress-core/ Make/Core] :)

 I'd like to start adding "official" support for remote dev environments to
 contribute to core (including testing) - I believe this makes
 contributions more accessible to a wider audience, by making fully-
 featured dev environments available on more devices and getting people
 started much faster (i.e. you click a button on a repo instead of braving
 conference wifi to download Docker images or passing around USB sticks).

 This ticket is more specifically for devcontainer + Codespaces support in
 core so you can start a Codespace from GitHub web - devcontainers are a
 set of config files that can be used with local Docker as well via VSCode
 (and otherwise). Codespaces is a GitHub-hosted solution to then run those
 devcontainers in the cloud (Azure) with the default ability to open VSCode
 for the Web connected to said container for a completely in-browser
 experience, meaning you can have a fully-featured code editing, building,
 and app running experience on a tablet.

 Here's what I think is needed but need opinions on where we should have
 boundaries between published images, devcontainers, and setup scripts as I
 am not myself particularly knowledgeable about containers

 * A baseline image that can be used for any number of dev needs - core,
 Gutenberg, other plugins and themes, testing, etc. This should probably
 include Composer, the appropriate Node+npm versions, and wp-cli. I have
 never yet gotten Xdebug to work in Codespaces. My current PR uses the
 Docker-published `wordpress` image, not the ones we use for `wp-env` -
 seems to me it would be nice to have something that spins up faster but I
 don't know enough here.
 * A `devcontainer.json` that includes some VSCode extensions (or
 explicitly decide not to include any).
 * Documentation, esp in the Make/Core Handbook. :)

 Full disclosure: I do currently work at GitHub; not in this area, but I do
 have access to helpful resources as needed. There are a number of services
 out there for remote dev with varying tiers of free usage, over time it
 would be great to support multiple options.

--

Comment:

 I'm pulling this into the 6.2 milestone to indicate my intention to commit
 this, though I'm going to consider it "beta support" for Codespaces and we
 can kick it to a future milestone for further work as makes sense. It has
 no impact on the core build as everything is outside of `src` so I have no
 qualms about bringing it in during beta, though I will wait a day or so
 for any discussions folks might want to have about this.

 I got some help from an engineer on Codespaces (samruddhikhandale) who's
 made this more robust as a first run and it would be great to have this in
 `trunk` so that folks can try it out at the upcoming WordCamp Asia
 contributor day on February 17. If you haven't yet used Codespaces, this
 allows people to essentially "hit play" and a cloud container spins up
 with trunk running from `src` installed at a portforwarded URL (private by
 default but can even be opened to the public), and VSCode connects to it
 from the browser or the desktop app. This does mean requiring connectivity
 to work, but contributors won't need to download images to their machines
 over venue wifi, and can even contribute from mobile devices and tablets
 with the in-browser VSCode option. 120 "core hours" are free for
 individual users, which really equates to 60 hours of usage at 2 cores
 (decent) or 30 hours at 4 cores (zippy). The underpinning of this is a
 devcontainer, which is an open spec that means you can also run the same
 environment via local Docker or any other tool that supports
 devcontainers. I just happen to be able to solicit direct help from my
 coworkers who are specifically working to enable OSS adoption of the tool
 and we have the GH mirror already :)

 I would very much value feedback from a contributor day type of event so
 that we as a project can make a decision about whether this is worth
 getting further help on solidifying a container strategy, as the current
 iteration relies on the `wordpress` image that is actually published by
 Docker, not us. That's the primary reason I would consider this "beta
 support". I've also not tested multisite or running any tests in the
 container.

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