CircleCI DIDI-II test never runs the container registry fetch #3184

Summary

DIDI-II is the CircleCI test workflow for a database-in-image project that fetches its database from the container registry. Its database job sets VORTEX_FETCH_DB_SOURCE to VORTEX_CONTAINER_REGISTRY, which isn't a source vortex-fetch-db knows, so no fetch script runs and the job passes without ever exercising vortex-fetch-db-container-registry.

Details

Where the value comes from

.vortex/tests/generate-vortex-dev-circleci builds the vortex-dev-database-ii job with 'VORTEX_FETCH_DB_SOURCE' => 'VORTEX_CONTAINER_REGISTRY', and that value lands in the generated .circleci/vortex-test-common.yml.

vortex-fetch-db only routes ftp, url, acquia, lagoon, container_registry and s3. Any other value runs no fetch script, but the router still touches the semaphore file and prints Finished database fetch., so nothing downstream notices.

What the job actually does

From DIDI-II database job 77163 (run on #3180):

• The Fetch DB step prints Started database fetch. and Found existing database dump file(s). (an 829 MB db.tar restored from the vortex-dev-didi-ii database cache), then Will fetch a fresh copy of the database. and Finished database fetch., with no container image fetch output in between.
• The Export DB step still reports Existing site found : Yes, so the data came from the database service build. Most likely docker compose up pulled drevops/vortex-dev-mariadb-drupal-data-demo-destination-11.x:latest on its own. The start of that log is cut off by CircleCI's step output limit, so the pull line isn't visible.

So DIDI-II goes green without touching anything in vortex-fetch-db-container-registry: the registry login, the host image check, the image pull, and the db.tar archive load and save. That's the path the workflow exists to test.

To fix

1. Set 'VORTEX_FETCH_DB_SOURCE' => 'container_registry' in .vortex/tests/generate-vortex-dev-circleci and regenerate with php .vortex/tests/generate-vortex-dev-circleci.
2. Expect DIDI-II to behave differently once the registry script runs, including how it handles the cached 829 MB db.tar. Read the DIDI-II Fetch DB and Export DB logs after the change rather than trusting a green job.
3. Add COMPOSE_PROGRESS: plain to the job, as [#3177] Fixed the nightly database job to import the fetched dump into a clean 'VORTEX_DB_IMAGE_BASE' image. #3180 does for the DIDI-FI database job, so the start of the Export DB log stays readable.

Related

#3182 ports the DIDI test workflows to GitHub Actions. That port should use container_registry rather than copy this value.