Martin Vogel cbe2b420d6 feat(docker): an image a skaffold or compose file builds DEPENDS_ON its Dockerfile ...

The image a workload runs and the Dockerfile that builds it were not
joined: Service -> Deployment -> Image stopped there. Build
configurations now say which Dockerfile builds which image:

- skaffold: build.artifacts (top level and profiles) with the docker
  builder -- image, context (default the file's directory),
  docker.dockerfile (default Dockerfile, relative to the context);
  ko / jib / bazel / buildpacks / custom / kaniko artifacts are none.
- compose: services with build (a context, or context / dockerfile)
  and image; ${X}, ${X:-d}, ${X-d}, $X from the project's .env.

Each becomes Image -DEPENDS_ON {via: build, tool, file, image, line}->
the Dockerfile's Module (pass_ci.c reads the YAML, pass_docker.c
links). On microservices-demo the chain is now whole:
Service/frontend -> Deployment/frontend -> Image frontend ->
src/frontend/Dockerfile -> main (src/frontend/main.go).

These edges belong to the build configuration declaring them, not to
either end, so every run recomputes them whole from all build files
(read through the File nodes, on every route): the incremental routes
drop the old set first (the staging graph before the delta patch, the
full-load buffer before the inbound-edge capture), and the delta patch
writes them even between nodes that both pre-existed.
cbm_gbuf_delete_edges_from_label / cbm_delta_drop_edges_from_label
delete a type's edges by source label.

Signed-off-by: Martin Vogel <martin.vogel.tech@gmail.com>

2026-10-11 14:00:29 +02:00

..

graph_buffer.c

feat(docker): an image a skaffold or compose file builds DEPENDS_ON its Dockerfile

2026-10-11 14:00:29 +02:00

graph_buffer.h

feat(docker): an image a skaffold or compose file builds DEPENDS_ON its Dockerfile

2026-10-11 14:00:29 +02:00