Summary
The Export DB step diverges between the two CI providers, and the divergence traces to a feature gap: database-in-image storage is implemented only in CircleCI, not in GitHub Actions.
This surfaced while fixing #2621 (the missing copy-out of the processed dump in PR #2622). The CircleCI copy-out had to be guarded on the dump file existing in the container, because in image mode export-db routes to export-db-image, which builds a Docker image and writes no /app/.data/db.sql. GitHub Actions has no image-mode path, so its copy-out is unconditional. The two lines therefore differ:
GHA: docker compose cp -L cli:/app/.data/db.sql .data/db.sql
CircleCI: docker compose exec -T cli test -f /app/.data/db.sql && docker compose cp -L cli:/app/.data/db.sql .data/db.sql || true
Evidence of the gap
.github/workflows/build-test-deploy.yml contains no VORTEX_DB_IMAGE references at all; the database job is file-based only.- The GitHub Actions copy-in is strict (no
|| true), so with no .data/db.sql present it fails at the copy-in - the job cannot complete in image mode.
.circleci/config.yml handles image mode throughout: the database job has grep -q ^VORTEX_DB_IMAGE .env && rm .data/db.sql || true, the nightly job sets VORTEX_DB_IMAGE_BASE, and the CircleCI test matrix exercises both vortex-dev-didi-database-fi (file) and vortex-dev-database-ii (image).
Impact
- Consumers who choose GitHub Actions cannot use database-in-image storage, while CircleCI consumers can. This limitation is currently undocumented.
- The
Export DB step (and the wider database/build flow) reads differently per provider, which adds maintenance friction - the copy-out guard asymmetry above being one example.
Options
- Bring GitHub Actions to parity - implement database-in-image in the GitHub Actions
database/build jobs (image cleanup, the guarded copy-out, the VORTEX_DB_IMAGE plumbing) and add a GitHub Actions image-mode test equivalent to vortex-dev-database-ii.
- Make the divergence explicit - document database-in-image as CircleCI-only and keep the GitHub Actions path file-only by design (current behaviour), so the per-provider differences are intentional and recorded.
Context
Found while reviewing #2621 / PR #2622. That PR deliberately keeps the provider-specific copy-out lines (GitHub Actions unconditional, CircleCI guarded on file existence) rather than papering over the gap. This ticket tracks the underlying reconciliation.
Summary
The
Export DBstep diverges between the two CI providers, and the divergence traces to a feature gap: database-in-image storage is implemented only in CircleCI, not in GitHub Actions.This surfaced while fixing #2621 (the missing copy-out of the processed dump in PR #2622). The CircleCI copy-out had to be guarded on the dump file existing in the container, because in image mode
export-dbroutes toexport-db-image, which builds a Docker image and writes no/app/.data/db.sql. GitHub Actions has no image-mode path, so its copy-out is unconditional. The two lines therefore differ:Evidence of the gap
.github/workflows/build-test-deploy.ymlcontains noVORTEX_DB_IMAGEreferences at all; thedatabasejob is file-based only.|| true), so with no.data/db.sqlpresent it fails at the copy-in - the job cannot complete in image mode..circleci/config.ymlhandles image mode throughout: thedatabasejob hasgrep -q ^VORTEX_DB_IMAGE .env && rm .data/db.sql || true, the nightly job setsVORTEX_DB_IMAGE_BASE, and the CircleCI test matrix exercises bothvortex-dev-didi-database-fi(file) andvortex-dev-database-ii(image).Impact
Export DBstep (and the wider database/build flow) reads differently per provider, which adds maintenance friction - the copy-out guard asymmetry above being one example.Options
database/buildjobs (image cleanup, the guarded copy-out, theVORTEX_DB_IMAGEplumbing) and add a GitHub Actions image-mode test equivalent tovortex-dev-database-ii.Context
Found while reviewing #2621 / PR #2622. That PR deliberately keeps the provider-specific copy-out lines (GitHub Actions unconditional, CircleCI guarded on file existence) rather than papering over the gap. This ticket tracks the underlying reconciliation.