Run Behat in throwaway containers when Docker is available

Abierto
  • ¿Algo no está bien?
#391 2 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
45/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
docker, php
Área
testing

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
PHP
Estrellas
42
Forks
28
Merge medio
17 h 14 min
PR fusionados (30 d)
11

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de wp-cli/wp-cli-tests

Todos los issues de wp-cli/wp-cli-tests

Issues similares

Más issues de PHP

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.