0.0.126: generated Dockerfile COPYs runtime-access.sql from context root, but agent stages it under builder/ in the service-dir build context

[antoinetoussaint-byte]

Root cause (not the same as the #68 symptom)

0.0.126 regressed the store container build again, but the mechanism is now precise and different from #68's "file missing" framing. The generated Dockerfile's COPY path no longer matches where the agent places the file in the build context codefly build service actually uses.

The regression, exactly

Version	Generated Dockerfile line	runtime-access.sql location in the service-dir build context	Build
0.0.124	COPY builder/runtime-access.sql /app/runtime-access.sql	builder/runtime-access.sql	✅ builds
0.0.126	COPY runtime-access.sql /app/runtime-access.sql	still builder/runtime-access.sql (nothing at context root)	❌ fails

0.0.126 dropped the builder/ prefix from the COPY without relocating the file. In the build context codefly uses (the service directory), there is no runtime-access.sql at the root, so:

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

Proof the recipe content itself is fine — the mismatch is context vs COPY-path

0.0.126 also records a build-recipes/0.0.126/ tree (schema codefly.dev/build-recipe/v1) whose own layout puts runtime-access.sql at the recipe root and the Dockerfile at builder/Dockerfile. Building with the recipe dir as the context succeeds cleanly:

$ cd module/services/store/build-recipes/0.0.126
$ docker build -f builder/Dockerfile .
#11 [7/7] COPY runtime-access.sql /app/runtime-access.sql DONE 0.1s
... naming to ...:latest DONE # image builds + exports

So the recipe is self-consistent when its own directory is the context. But codefly build service runs the build with the service directory (module/services/store/) as the context — where runtime-access.sql lives under builder/, not at the root. The generated Dockerfile's COPY paths (runtime-access.sql, migrations) are written relative to the recipe root, while the build executes against the service-dir root. The two layouts are off by the builder/ level.

Fix (pick the side that owns the contract)

• Agent-side (matches 0.0.124's working behavior): emit COPY builder/runtime-access.sql /app/runtime-access.sql so the COPY path matches the file's location in the service-dir context; or stage runtime-access.sql at the service-dir context root.
• Contract-side: if build-recipe/v1 intends the build context to be build-recipes/<version>/ (which builds correctly), the agent's emitted build plan must point codefly build service's context at the recipe dir rather than the service dir.

Either way the invariant to restore is: the context root the build runs against must contain runtime-access.sql at the path the generated Dockerfile COPYs.

Environment

• Reproduced with CI's exact toolchain: go install github.com/codefly-dev/cli/cmd/codefly@latest → cli v0.1.139, codefly build service.
• Any postgres service with spec.runtime-read-write-roles. 0.0.124 builds; 0.0.125 and 0.0.126 fail (different COPY paths, same root mismatch).
• Consumer held at 0.0.124 in module-saas-starter. Supersedes the 0.0.125 breaks container build: builder/runtime-access.sql missing from staged build context #68 framing.

[antoinetoussaint-byte]

Source-level root cause (traced through both repos)

The failure is a CLI↔agent disagreement on what the recipe's Context resolves to.

Agent (this repo, builder.go):

• buildRecipe emits the plan with Context: "." (services.BuildDockerBuildPlan(outputDirectory, []*DockerBuildRecipe{{ … Context: "." }})).
• renderRuntimeAccess(ctx, docker, outputDirectory) writes runtime-access.sql at the output/recipe root.
• templates/builder/Dockerfile.tmpl:23 → COPY runtime-access.sql /app/runtime-access.sql (root-relative).

CLI (codefly-dev/cli@v0.1.139, pkg/orchestration/build_plan.go):

// buildRecipeDir = "builder" … the Dockerfiles COPY builder/… paths
// relative to the service-directory context.
func recipeContext(serviceDir string, recipe *builderv0.DockerBuildRecipe) (string, error) {
 relative := recipe.GetContext()
 if relative == "" || relative == "." {
 return serviceDir, nil // <-- "." resolves to the SERVICE dir
 }
 …
}

…while recipeDockerfile resolves the Dockerfile against outputDir. So the CLI is itself inconsistent: Dockerfile path relative to outputDir, but build context = serviceDir. When those differ, COPY runtime-access.sql looks in serviceDir/ where the file isn't (it's under builder/), and the build fails:

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

Evidence isolating it: docker build -f builder/Dockerfile . inside the emitted build-recipes/0.0.126/ (the context the agent assumes) succeeds; codefly build service (the service-dir context the CLI actually uses) fails.

Fix — pick one side of the contract

1. Agent (matches CLI's documented builder/ convention and 0.0.124's working behavior): render runtime-access.sql at builder/runtime-access.sql and emit COPY builder/runtime-access.sql /app/runtime-access.sql. Smallest change; restores the invariant the CLI documents.
2. CLI: make recipeContext resolve Context: "." to the recipe outputDir (consistent with how recipeDockerfile already resolves), so the agent's "context = recipe tree" intent holds. This likely needs a matching change/issue in codefly-dev/cli.

Option 1 is the lower-risk fix and keeps the CLI's stated convention. Happy to open the PR (revert the template's COPY to builder/runtime-access.sql + a build test) if you confirm that's the side you want it fixed on.

[antoinetoussaint-byte]

Fix confirmed empirically ✅

Built 0.0.126 from source (codefly agent build --native-only) and reproduced via codefly build service --local-agents on module-saas-starter's store. Then tested the fix direction:

Placing runtime-access.sql at the service-dir root (beside migrations/) makes the build pass — COPY runtime-access.sql resolves, image exports, Work done!.

So PR #69's Dockerfile change (COPY runtime-access.sql from the context root) is correct — the CLI builds with context = b.instance.Service.Dir() (service root), which is exactly why COPY migrations already works (migrations/ sits at that root). The one remaining bug: renderRuntimeAccess doesn't land the file at the service-dir root — it ends up under builder/. Fix = render runtime-access.sql to the service-dir context root (beside migrations/), so the COPY the template already emits resolves.

Ready-made verification harness

# in service-postgres worktree, after your fix:
codefly agent build --native-only --skip-audit # installs local 0.0.126

# in module-saas-starter, store pinned to 0.0.126:
cd module/services/store && codefly build service --local-agents
# expect: COPY runtime-access.sql … DONE → Work done!

The failing state shows COPY runtime-access.sql … "/runtime-access.sql": not found; a correct fix shows it resolving and the image exporting.

(FYI a locally-built 0.0.126 is now installed at ~/.codefly/agents/services/codefly.dev/postgres__0.0.126 from my repro — rebuild overwrites it.)