Run Behat in throwaway containers when Docker is available

Ouverte
  • Quelque chose ne va pas ?
#391 2 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
45/100
Type d'issue
Fonctionnalité
Clarté
Plutôt claire
Activité
Active
Stack technique
docker, php
Domaine
testing

Piste de recherche

Read #390 to see the worker design and #384 for the baseline timing. The repo likely needs a Dockerfile for a tuned PHP image without Xdebug, and changes to the test runner to launch throwaway containers per worker. Done when a draft PR runs CI jobs with containerized Behat and shows snapshot restore working. Fallback to regular runner must remain when Docker is absent.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

scope:testing status:unconfirmed

When Docker is available, a run could happen in throwaway containers, one per worker from #390. The container is not faster by itself: PHP ran at the same speed inside and outside of it in local tests. What it allows without root on the host is what makes the difference:

  • the temporary directories and the database in memory, with no disk syncs;
  • copy-on-write snapshots of the cached WordPress install instead of a full copy for every scenario (about 6 ms instead of about 90 ms to set up and tear down);
  • a separate network per worker, so scenarios using fixed ports can run in parallel;
  • a known toolchain, so every declared test requirement is present.

Starting a container takes about 0.3 to 0.5 seconds and every docker exec about 50 to 75 ms. Running the whole Behat process of a worker inside one container avoids that cost per command. The container's PHP version has to match the one the vendor folder was installed for.

Steps:

  1. Provide an image tuned for the test runs, without Xdebug unless coverage is requested.
  2. Run each worker of #390 in its own throwaway container, falling back to the regular runner when Docker is not available.
  3. Restore the cached WordPress install as a snapshot instead of a copy.

To reproduce a failure, it is enough to rerun that single scenario in a container that is kept.

Measuring: take the baseline from #384, then open a draft PR, run the same CI jobs against it and record both results here before we decide.

Langage dominant
PHP
Étoiles
42
Forks
28
Merge moyen
18 h 52 min
PR mergées (30 j)
27

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de wp-cli/wp-cli-tests

Toutes les issues de wp-cli/wp-cli-tests

Issues similaires

Plus d'issues PHP

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.