Use a prebuilt Docker image for the parallel workers

Offen
  • Stimmt etwas nicht?
#425 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
25/100
Issue-Typ
Feature
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
docker, github-actions, php
Bereich
ci-cd, devops, testing

Rechercherichtung

Start with wp_cli_tests_docker_php_image() in utils/behat-parallel.php and the image definition in utils/docker/Dockerfile, then look at the existing GitHub Actions workflows for where a publish job would go. Done means the helper computes a tag from the PHP version and a hash of utils/docker/, pulls that image, and falls back to the local build when the pull fails or the hash differs. The publishing workflow should push images for each supported PHP version to GHCR.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

scope:testing

Part of #394. Follow-up to #391 and #408.

Every Linux Behat job builds the worker image from utils/docker/Dockerfile with docker build (wp_cli_tests_docker_php_image() in utils/behat-parallel.php). The GitHub runners start without a layer cache, so every job builds the image from scratch, although it only depends on the PHP version and the Dockerfile.

In the full-matrix runs of all 29 packages on 2026-11-02, the time from the start of the Behat step to the first worker starting was between 40 and 63 seconds in every package, measured in the job for PHP 8.4, WP latest and MySQL 8.0. Each package runs about 45 Linux Behat jobs, so this adds up to roughly 30 to 45 runner-minutes per package per Testing run, or about 15 to 20 runner-hours per round across the 29 packages. For PHP 8.0 and older, the image also builds SQLite from source (#413), which takes another 30 to 90 seconds.

Proposal:

  1. A workflow in this repository builds the image for every supported PHP version and publishes it to the GitHub Container Registry, tagged with the PHP version and a hash of utils/docker/. It runs when the Dockerfile changes, and on a schedule, to pick up PHP patch releases and security updates of the base images.
  2. wp_cli_tests_docker_php_image() computes the same tag and pulls the image. It builds the image locally as before if the pull fails, or if utils/docker/ differs from any published version, for example in a development checkout.
  3. Keep the image small, so pulling it stays well below the current build time.

The vendor directory for a different PHP version (WP_CLI_TEST_DOCKER_PHP) is project-specific and stays out of the image.

Measuring: compare the time from the start of the Behat step to "Running N scenarios ..." for the same jobs, with a cold runner, before and after. Pull time is what decides this, so record the size of the image as well.

Vorherrschende Sprache
PHP
Sterne
42
Forks
28
Ø Merge
18 Std. 52 Min.
Gemergte PRs (30 T.)
27

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus wp-cli/wp-cli-tests

Alle Issues in wp-cli/wp-cli-tests

Ähnliche Issues

Weitere Issues zu PHP

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.