Run Behat in throwaway containers when Docker is available

Aberta
  • Algo errado?
#391 2 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
45/100
Tipo de issue
Funcionalidade
Clareza
Razoavelmente clara
Status de atividade
Ativa
Stack de tecnologia
docker, php
Domínio
testing

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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.

Linguagem predominante
PHP
Estrelas
42
Forks
28
Merge médio
18h 52min
PRs com merge (30d)
27

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de wp-cli/wp-cli-tests

Todas as issues de wp-cli/wp-cli-tests

Issues semelhantes

Mais issues de PHP

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.