ci(github): add container support for self-hosted runners

[dipankardas011]

What

Switch all workflows to use containers on self-hosted runners for improved
consistency and isolation. Add system dependency installation steps and
configure Docker and Git safe directory where needed. Update job dependencies
and permissions for better security and workflow reliability. This enables
better compatibility with shared self-hosted environments.

[justlevine]

@dipankardas011 is there a way to cache those install commands? Setting up docker, php, reinstalling npm deps... (not composer, since that's handled by our action)

[justlevine]

I was able to get rid of the (hopefully) unnecessary WP_TESTS_ENV_PORT everywhere when I fixed the .tests.wp-env.json file . I'm pretty sure we can get rid of this one too but the CI is waaay to slow and I ran out of time to try. What do you think?

As a reminder, we're using wp-env 11.1. so there's 1 encironment in a JSON and it defaults to the prt defined in the JSON or the constant

[justlevine]

@dipankardas011 I've restored the public gh runners to live alongside these private one, and started on some cleanup regarding the @wordpress/env<11 issues.

I ran out of time to finish testing because of how slow things are, so please review and finish up what else is needed. As you can see both PHPUnit and Playwright E2E tests are passing on the GH runners, so they should all be passing on the private runner side too. 🙇

Edit: and they are 🚀 So just playground and cleanup/optim left.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 94.94%. Comparing base (bbe8008) to head (15cdf92).

Additional details and impacted files

@@            Coverage Diff            @@
##               main       #9   +/-   ##
=========================================
  Coverage     94.94%   94.94%           
  Complexity      115      115           
=========================================
  Files            21       21           
  Lines           475      475           
=========================================
  Hits            451      451           
  Misses           24       24           

Flag	Coverage Δ
unit	94.94% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[dipankardas011]

@justlevine I saw your recent changes to the Public workflows which you created test-public-workflows.yml I saw that some jobs phpunit, jest, lint-css-js they are not using the public reusable workflow which you created. It seems like you do need that, also the playwright error of dependency I fixed it.

Seems like workflow is working, Not sure why the composer.yaml Refer is not found may be the changes from the main branch had a problem it seems I guess.

[dipankardas011]

@dipankardas011 is there a way to cache those install commands? Setting up docker, php, reinstalling npm deps... (not composer, since that's handled by our action)

So what I can see is we have a single self-hosted runner and when job run happens it only assign one at a time. this is where we are getting the Major slowdown.

and then comes up is the setup of the workload like adding system deps Yes ~7m each but then comes another point that not all of them needs to be tested thanks to dorny/paths-filter.

[justlevine]

and then comes up is the setup of the workload like adding system deps Yes ~7m each but then comes another point that not all of them needs to be tested thanks to dorny/paths-filter.

Not sure I followed this. Are you saying there's no way to cache these steps between workflows? A single PHP change will (correctly) trigger

• Building the plugin
• Playground Preview
• PHPCS
• PHPStan
• PHPUnit (let's pretend it's a client project and we only need 1 php+wp combo)
• E2E Tests.

That's ~30 minutes in duplicate setup time (im guessing based on when the tests were last passing). not waiting for a runner to become available.

[dipankardas011]

Not sure I followed this. Are you saying there's no way to cache these steps between workflows? A single PHP change will (correctly) trigger

As we are running inside docker and the only way (provided we are READY to maintain a separate OCI image in this repo's ghcr.io registry and same for the workflow file, Point is do we need that? Let me know)

as you pointed out yes ~30minutes the only steps we can getinside the container are

1. "Install system dependencies" (The Big Time Saver)
   In every job, you are running apt-get update and apt-get install. We can bake all of these into the image:

• git, curl, sudo, unzip, jq (Common to all)
• socat (Specifically for E2E tests)
• gh (GitHub CLI, used for your Playground Previews)
• Playwright System Deps: npx playwright install-deps. This is huge—it installs about 20+ Linux libraries (like libatk, libcups, libgbm) that take forever to download and install every time.

2. "setup Docker"
   currently running the get-docker.sh script in every job.

• We can install the Docker CLI and engine components directly into the image. This saves the time spent downloading and running the installation script.

3. "Configure Docker group permissions" (Partial)

• Bake it: useradd -m wpuser. We can pre-create the user and set up their home directory.
• Runtime Only: The groupmod -g $SOCK_GID part must stay in the YAML because the GID of /var/run/docker.sock changes depending on which host machine the runner is on.

4. "Setup Node.js" (Optional but recommended)
   While actions/setup-node is fast, we could actually pre-install Node.js and npm at the specific version you use (from .nvmrc) into the image. This removes one more "Action" from your YAML.

If you check how much in total of the workflow runtime it is and whether its worth it or not.

[dipankardas011]

@justlevine I came across a different approach of using the github's official ubuntu24.04 image

I tried to change only the workflow .github/workflows/reusable-build.yml
91912eb

But it seems like the composer is failing I don't know what is the problem anyone who knows that? after that is fixed I can then check if this modified build (private) one is working then I will update the rest of the private workflows ;)

I refered to this https://github.com/actions/runner-images/releases/tag/ubuntu24%2F20260309.50

Caution

for now I did used a tag some 2.33 something which when ran it for /etc/os-release gave me the ubuntu:24.04 lts and it was the latest based on the release and tag it was attached for using that