Run Behat in throwaway containers when Docker is available

Open
#391 2 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
45/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
docker, php
Domain
testing

Research direction

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.

Written by the indexing model from the issue text.

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.

Dominant language
PHP
Stars
42
Forks
28
Avg merge
17h 14m
Merged PRs (30d)
11

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from wp-cli/wp-cli-tests

All issues in wp-cli/wp-cli-tests

Similar issues

More PHP issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.