Skip to main content

Build: DDEV CI Acceleration Playbook with WarpBuild for Drupal Pipelines

· 3 min read
Victor Jimenez
Victor Jimenez
Software Engineer & AI Agent Builder

Use WarpBuild runners for the compute-heavy parts of your DDEV Drupal pipeline, keep cache keys deterministic, and gate rollout by p95 runtime and failure-rate SLOs. This gives you faster CI without turning your pipeline into a probabilistic black box. I verified this playbook against DDEV v1.25.1 (released February 23, 2026) and current WarpBuild runner/cache docs.

The Problem​

Drupal CI pipelines that boot DDEV, run Composer, and execute tests typically lose time in three places:

BottleneckTypical symptomWhy it hurts
Cold VM startupSlow first job on each PRAdds fixed latency to every run
Dependency re-downloadComposer cache missesRepeats network + unzip work
Unsafe rolloutTeam flips all jobs at onceOutages hide whether speed gains are real

Without a reproducible benchmark method, "CI feels faster" is not a decision signal.

The Solution​

I use one workflow template and one benchmark script as the source of truth:

  • Workflow template: examples/devops/ddev-warpbuild-drupal-ci.yml
  • Benchmark script: examples/devops/benchmark-ddev-ci.sh
# from examples/devops/ddev-warpbuild-drupal-ci.yml
jobs:
  test:
    runs-on: warp-ubuntu-latest-x64-4x
    steps:
      - uses: actions/checkout@v4
      - uses: actions/cache@v4
        with:
          path: ~/.cache/composer
          key: composer-${{ runner.os }}-${{ hashFiles('**/composer.lock') }}
      - uses: ddev/github-action-setup-ddev@v1
      - run: ddev start
      - run: ddev composer install --no-interaction --prefer-dist
      - run: ddev exec phpunit -c web/core
# from examples/devops/benchmark-ddev-ci.sh
./examples/devops/benchmark-ddev-ci.sh \
  acme/drupal-platform \
  drupal-ci-github-hosted.yml \
  drupal-ci-warpbuild.yml \
  20

Cache strategy​

LayerKey strategyEviction/limit concernGuardrail
Composer (actions/cache)hashFiles('**/composer.lock')GitHub cache quotas and eviction policyKeep caches lockfile-scoped; do not share mutable keys
DDEV runtime warmupWarm via ddev start + smoke commandCold starts still happen on new runnersTrack cold vs warm p95 separately
WarpBuild runner cache/snapshotsPrewarm common toolchain pathsSnapshot drift can hide breakagesWeekly cold-run canary with snapshots disabled

Rollout guardrails for Drupal teams​

  1. Shadow mode first: run WarpBuild workflow in parallel, but do not block merges for one week.
  2. Promote only if p95 runtime improves by at least 20% and failure rate does not regress.
  3. Keep one baseline GitHub-hosted workflow as a canary for two release cycles.

Related reading: DDEV v1.25 modular share architecture, DDEV Podman/rootless constraints, and Composer path repo workflow for Drupal.

What I Learned​

  • WarpBuild acceleration works best when compute and cache are tuned together; compute alone is not enough.
  • Deterministic cache keys beat "mega-cache" strategies for Drupal reliability.
  • A permanent baseline lane prevents overfitting CI to one runner platform.

References​