13.1.2.4 CI Disposable Environments
A focused guide to CI Disposable Environments, connecting core concepts with practical Docker and container operations.
CI disposable environments are the entire set of containers, networks, and volumes a CI pipeline run brings up specifically for that run, fully torn down afterward, reflecting the broader principle that a CI environment's state should never be expected to persist or be relied upon between separate runs.
Why Disposability Is a Deliberate Design Principle for CI
Treating every CI run's environment as entirely disposable — created fresh, torn down completely — ensures no run can be inadvertently affected by leftover state from a previous one.
jobs:
test:
steps:
- run: docker compose -f docker-compose.test.yml up -d
- run: docker compose -f docker-compose.test.yml run --rm app npm test
- run: docker compose -f docker-compose.test.yml down -v
The final teardown step, including volume removal, ensures absolutely nothing from this run persists for the next one.
Why This Matters Even When CI Runners Are Already Ephemeral
Many CI platforms already provide fresh, ephemeral runner machines for each job — but explicitly tearing down the application's own containers and volumes provides an additional, deliberate guarantee, rather than relying entirely on the underlying runner's own ephemerality.
docker compose -f docker-compose.test.yml down -v
This step matters even on an ephemeral runner, since it's specifically about the application's own resources, not just the broader runner environment.
Avoiding Reliance on Any Implicit, Persisted State
A CI pipeline that subtly relies on some artifact or state happening to persist from a previous run (without explicit, intentional caching) risks unpredictable, hard-to-diagnose failures whenever that assumption doesn't hold.
docker volume ls
Confirming no application-specific volumes remain after a teardown validates that disposability is actually being achieved.
Explicitly Caching Specific, Intended Artifacts Instead
Where genuine speed benefits from reusing something between runs (build caching, for instance), this should be done explicitly and deliberately, rather than through implicit reliance on accidental, undisposed state.
- uses: actions/cache@v4
with:
path: /tmp/.buildx-cache
Why CI Disposable Environments Matter
Treating CI environments as fully disposable, with explicit teardown after every run, is foundational to achieving the reliable, reproducible test results that make CI genuinely trustworthy as a verification gate.