Skip to content

Defer CI dev-dependency install until after the database cache is captured #2636

Description

@AlexSkrypnyk

Summary

Defer the Install development dependencies step in the CI test job until after the database cache is captured (saved), so the cache is stored before the slow composer-dev + yarn install rather than after it.

This is a follow-up optimization to #2627, which folded the database download + first-build-of-day caching into the test job. In #2627 the dev-dependency install currently runs before the cache is captured; reordering it is deferred to here.

Why it is safe

The cache capture (Download DB + the Export DB after download step: a raw import via provision with VORTEX_PROVISION_POST_OPERATIONS_SKIP=1, then export-db, then copying the processed dump back to the host) needs only the prod dependencies - drush and drevops/vortex-tooling - which are already baked into the cli image by .docker/cli.dockerfile (composer install --no-dev ...) and present the moment docker compose up finishes. The dev dependencies (PHPUnit/Behat) and yarn packages are only needed by the test steps. The old standalone database job captured this exact cache with no composer install step at all, confirming dev deps are not a prerequisite.

Benefits

  • The cache lands sooner on the first build of the day (before the ~1-3 min dev-deps + yarn install), so concurrent/later builds that day pick it up faster.
  • The cache survives downstream failures: if composer install/yarn install (or provision/tests) flake, the expensive download + export is already persisted instead of being thrown away and re-downloaded next run.

Target order

Build stack -> Download DB -> Export DB (capture) -> Save cache -> Install dev deps -> Provision -> Tests

Provider notes

  • GitHub Actions (.github/workflows/build-test-deploy.yml): straightforward. The save is already gated by if: matrix.instance == 0 (no file deletion), so just move Install development dependencies to after Save DB cache.
  • CircleCI (.circleci/config.yml): needs a decision. The current node-0 save guard works by deleting .data on non-primary runners right before save_cache, and that runs after provision because provision still needs .data - both the main dump on a cache hit and the migration db2.sql on every cache-miss run. To move the save before provision, the guard has to change. Options:
    1. Write-once cache - both runners run save_cache with the same key; CircleCI keeps only the first write. Simplest, makes both providers identical, cache survives all later failures. Cost: both runners upload on the day's first build.
    2. Explicit guard via stash - stash .data aside on non-primary runners around save_cache, then restore it for provision. Preserves single-runner upload, keeps migration safe; adds two stash/restore steps.
    3. Minimal - leave the save after provision; only move Install development dependencies after it. Smallest change, but CircleCI then provisions on the baked prod image before dev deps are installed (asymmetric with GHA, and the cache is not saved if provision fails).

Regenerate .circleci/vortex-test-common.yml and the installer fixtures after the change.

Metadata

Metadata

Assignees

No one assigned

    Labels

    A2Working clone index A2

    Type

    No type
    No fields configured for issues without a type.

    Projects

    Status
    To do for current release

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions