Make WordPress Core

Changes between Initial Version and Version 5 of Ticket #57187


Ignore:
Timestamp:
02/09/2023 03:19:58 AM (20 months ago)
Author:
helen
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.

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #57187

    • Property Keywords has-patch added
    • Property Milestone changed from Awaiting Review to 6.2
  • Ticket #57187 – Description

    initial v5  
    55This 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.
    66
    7 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 😁
     7Here'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
    88
    99* 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.