[infra] Image tagging & orchestration inconsistencies break pulls/builds

[rahulkatiyar19955]

Severity

Medium

Summary

Image-tagging and orchestration logic is internally inconsistent: docker-compose.yml pins :latest tags that the publish workflow never pushes; the packaged orchestrator pulls :<appVersion> tags with nothing guaranteeing they exist; and the orchestrator's docker build ignores each service's dockerfile: and build args. Any of these breaks startup or builds the wrong image.

Findings

• Dev docker compose pull/up against GHCR is broken — docker-compose.yml:50,76,100,121,141,163,183 vs .github/workflows/docker-publish.yml:117-124 — all 7 services reference ghcr.io/.../datapilot-*:latest, but docker-publish.yml (metadata-action) only emits :<version> and :sha-<commit> tags and the comment explicitly says it avoids :latest. So :latest is never published and the documented compose stack fails with manifest unknown; dev only works via the build-from-source override. fix: publish a :latest tag on the default branch, or switch compose to a ${TAG:-latest} variable and document it, and align the docker-publish.yml comment.
• Packaged image-tag coupling has no guarantee the tag exists — src/main/dockerOrchestrator.ts:206-213 + .github/workflows/docker-publish.yml:109-124 — when packaged, resolveImageTag rewrites images to datapilot-*:${app.getVersion()}, but published tags come from package.json version and only match if every app release also had a successful image publish for that exact version. A re-tag, a failed build-docker job, or a hotfix app build without an image publish leaves the app pulling a non-existent tag → startup failure. There is no digest pinning and no fallback tag. fix: pin images by digest in the packaged compose, or emit the resolved tag/digest into the bundled compose at package time so app and images are versioned atomically.
• Orchestrator docker build ignores dockerfile: and build args — src/main/dockerOrchestrator.ts:251 — for build: services it runs docker build -t <imageTag> . with cwd = buildContext, hardcoding . and never passing -f <service.build.dockerfile> or --build-arg. Services whose Dockerfile is not <context>/Dockerfile (mcap-parser and all 5 workers use context . with a nested Dockerfile path) build the wrong image or fail, and backend/Dockerfile's ARG TARGETARCH is never set. fix: honor service.build.dockerfile (-f) and service.build.args; prefer dockerode/compose build semantics over a bare docker build ..

Project-rule reference

AGENT.md ### Docker & Orchestration (line 157) — Docker is orchestrated by the Electron main process via dockerode; the committed compose is the source of truth for service definitions.