0.0.125 breaks container build: builder/runtime-access.sql missing from staged build context

[antoinetoussaint-byte]

Regression

Postgres service agent 0.0.125 breaks the container build for any service that uses the generated COPY builder/runtime-access.sql step. 0.0.124 builds the same service cleanly.

Symptom

#10 [7/7] COPY builder/runtime-access.sql /app/runtime-access.sql
#10 ERROR: failed to calculate checksum of ref ...: "/builder/runtime-access.sql": not found
ERROR: failed to build: failed to solve: failed to compute cache key: "/builder/runtime-access.sql": not found

Diagnosis

The Dockerfile the agent generates in 0.0.125 still emits COPY builder/runtime-access.sql /app/runtime-access.sql, but the build context the agent stages no longer includes the builder/ directory (the transferred context contains migrations/ but not builder/). So BuildKit fails computing the cache key for that COPY. Under 0.0.124 the same COPY resolves because builder/ is present in the staged context.

Impact

Any postgres service with runtime-access role provisioning (spec.runtime-read-write-roles) fails codefly build service / codefly ci build on 0.0.125.

Repro

1. Pin a postgres service to 0.0.125.
2. codefly build service → fails as above.
3. Repin to 0.0.124 → builds and exports the image.

Workaround

Holding the pin at 0.0.124 in module-saas-starter until this is fixed.

[antoinetoussaint-byte]

Reopening evidence: 0.0.126 does not fix this for module-saas-starter's store service.

Verified with CI's exact toolchain — codefly@latest (v0.1.139), codefly build service:

#10 [7/7] COPY runtime-access.sql /app/runtime-access.sql
#10 ERROR: failed to compute cache key: "/runtime-access.sql": not found

What changed in 0.0.126:

• The generated Dockerfile's COPY moved from COPY builder/runtime-access.sql (0.0.125) to COPY runtime-access.sql (context root).
• A new build-recipes/0.0.126/ layout is emitted (schema codefly.dev/build-recipe/v1) containing builder/Dockerfile, runtime-access.sql, and migrations/.
• The old builder/Dockerfile is deleted.

But the build context is still rooted at the service dir, where the generated runtime-access.sql is nested (under builder/ and build-recipes/0.0.126/), not at the root the Dockerfile now COPYs from. So COPY . . and COPY migrations resolve, but COPY runtime-access.sql fails — same failure class as 0.0.125, just relocated.

Repro: pin a postgres service (with spec.runtime-read-write-roles) to 0.0.126 → codefly build service fails as above. 0.0.124 still builds cleanly. Could you reopen, or confirm whether a coordinated CLI change is required to root the build context at build-recipes/<version>/?