Docker Compose Build Race Condition in Fresh Vortex Projects

[IvanZugec]

Summary

When running ahoy build or ahoy up commands in newly created Vortex-scaffolded projects, builds consistently fail due to a race condition where services attempt to build before their dependencies are ready.

Environment

• Vortex Version: Latest (from DrevOps/vortex)
• Docker Version: Docker Desktop (4.42.1 (196648))
• Platform: macOS (14.7.6)
• Project State: Fresh scaffold, no modifications

Steps to Reproduce

1. Create a new project using Vortex scaffold
2. Run ahoy build (or ahoy up)
3. Observe build failure

Expected Behavior

• ahoy build completes successfully on first run
• ahoy up completes successfully on first run
• All containers build and start without manual intervention

Actual Behavior

Build fails with error messages like:

> [nginx internal] load metadata for docker.io/library/project-name:latest:
------
php.dockerfile:13
--------------------
  11 |     ARG CLI_IMAGE
  12 |     # hadolint ignore=DL3006
  13 | >>> FROM ${CLI_IMAGE:-cli} AS cli
  14 |
  15 |     FROM uselagoon/php-8.3-fpm:25.6.0
--------------------
target nginx: failed to solve: project-name: failed to resolve source metadata for docker.io/library/project-name:latest: pull access denied, repository does not exist or may require authorization

Current Workaround

docker compose build cli
ahoy build

This workaround works but shouldn't be necessary for new users.

Impact

• Developer Experience: Poor first impression for new Vortex users
• Onboarding: Additional friction when setting up projects
• Documentation Burden: Requires explaining workarounds
• CI/CD: Potential issues in automated environments
• Support Load: Generates support requests from confused developers

Affected Services

The issue affects multiple services that depend on the CLI image:

• nginx (nginx-drupal.dockerfile)
• php (php.dockerfile)
• solr (solr.dockerfile)

Technical Details

The error occurs because:

1. Multiple services reference CLI_IMAGE: *cli-image in their build arguments
2. Docker Compose attempts to build services in parallel
3. Services try to use FROM ${CLI_IMAGE} before the CLI service image exists
4. Docker attempts to pull the non-existent image from Docker Hub

Frequency

This issue occurs 100% of the time on fresh Vortex installations across all tested environments.

Related Files

• docker-compose.yml (service dependencies)
• .docker/nginx-drupal.dockerfile
• .docker/php.dockerfile
• .docker/solr.dockerfile
• .ahoy.yml (build command definition)

Environment Details

• Docker Compose Version: Docker Compose version v2.37.1-desktop.1
• Operating Systems: macOS (Docker Desktop)
• Container Runtime: Docker

[AlexSkrypnyk]

This is super strange. We have tests running fresh installs in CI.

Im wondering if something changed in the latest Docker.

I will look into this shortly.

[AlexSkrypnyk]

@IvanZugec
Could you please try applying changes from this PR https://github.com/drevops/vortex/pull/1780/files#diff-e45e45baeda1c1e73482975a664062aa56f20c03dd9d64a827aba57775bed0d3R122 and let me know if this worked for you.

Thank you

[AlexSkrypnyk]

Confirmed that Docker Compose v23.7.0 enabled bake by default that now uses parallel builds.

Vortex's CI runner (drevops/ci-runner) uses Docker Compose v23.6, which lead to this not being picked up.

[AlexSkrypnyk]

The solution is to add

      additional_contexts:
        cli: "service:cli"

as per https://github.com/drevops/vortex/pull/1780/files#diff-e45e45baeda1c1e73482975a664062aa56f20c03dd9d64a827aba57775bed0d3R122