Follow-up from PR #1975 review comment. The coordinator landed with dedicated
build/CI tooling (Makefile.coord.mk, .github/workflows/ci-coordinator.yaml) that
re-declares variables, container-runtime plumbing, and targets already defined for the
router build. This tracks investigating how much can share the existing infrastructure.
Questions to answer
- Should coordinator CI reuse existing workflows (
ci-pr-checks, ci-lint,
ci-build-images) instead of a dedicated ci-coordinator.yaml and merge gate?
- Is a separate
Makefile.coord.mk warranted, or should its targets be inlined into the
existing Makefiles? It duplicates defaults (TARGETOS, IMAGE_REGISTRY, builder image),
the docker/podman socket plumbing, and targets (presubmit, format, lint,
test-unit, image-build-%).
Follow-up from PR #1975 review comment. The coordinator landed with dedicated
build/CI tooling (
Makefile.coord.mk,.github/workflows/ci-coordinator.yaml) thatre-declares variables, container-runtime plumbing, and targets already defined for the
router build. This tracks investigating how much can share the existing infrastructure.
Questions to answer
ci-pr-checks,ci-lint,ci-build-images) instead of a dedicatedci-coordinator.yamland merge gate?Makefile.coord.mkwarranted, or should its targets be inlined into theexisting Makefiles? It duplicates defaults (
TARGETOS,IMAGE_REGISTRY, builder image),the docker/podman socket plumbing, and targets (
presubmit,format,lint,test-unit,image-build-%).