The plugin compilation lives in the shared builder stage, so the slim flavor pays for it too.

runtime (slim) copies /app/iggy-connectors and /app/LICENSE-binary out of builder. Both of those are produced by RUN layers that sit at or after this one, so --target runtime still executes this cargo zigbuild -p iggy-connectors $PLUGIN_FLAGS (17 cdylibs) and the license RUN below that also generates LICENSE-binary-fat. BuildKit cannot skip a layer that an earlier needed artifact depends on.

Net effect: the -slim build goes from a runtime-binary-only compile to roughly the full fat build time (~20 min per the PR description), plus a cargo-about pass over 18 dependency closures, and then discards all of it. With the matrix at flavors x arches that is two extra full plugin compiles per publish run.

Suggestion: keep builder producing only the runtime binary and LICENSE-binary, then add a stage that only the fat image consumes:

FROM builder AS plugin-builder
# cargo zigbuild ... $PLUGIN_FLAGS, collect /app/plugins, generate LICENSE-binary-fat

FROM runtime AS runtime-fat
COPY --from=plugin-builder /app/plugins/ /usr/local/lib/
COPY --from=plugin-builder /app/LICENSE-binary-fat /usr/share/doc/iggy-connect/LICENSE-binary

--target runtime then stops at builder and the slim image build is unchanged from today.

target now changes the build graph, but the buildx cache ref is still only component- and arch-scoped, so the two flavors fight over one cache entry.

The cache composition step above builds cache-to / cache-from as type=registry,ref=${img}:buildcache-${arch},mode=max (and the shared ${shared_deps}:buildcache-${arch}) with no flavor component. Since docker_matrix is now component x flavor x platform, the fat and slim jobs for the same arch run concurrently and both push mode=max to apache/iggy-connect:buildcache-amd64. The cache index is last-writer-wins, so each run one flavor's cache export is effectively lost, and cache-from may pull an index describing the other flavor's graph.

Layer integrity is fine (BuildKit verifies digests), but the fat build is the expensive one and is exactly the one that needs a warm cache. ${img}:latest in cache-from is also the fat image under the new tag scheme, which the slim build will now pull as inline cache.

Suggestion: thread the flavor into the cache ref, e.g. pass the flavor suffix into this action and use ${img}:buildcache${suffix}-${arch}, so each flavor keeps its own cache the same way it now keeps its own digest artifacts.

This turns a previously tolerated miss into a hard failure at the same time as the plugin set silently grows, so the first master push after merge is the first real exercise of the new set.

Old behaviour was [[ -f "$so_file" ]] && cp "$so_file" "${outdir}/", a soft skip. Combined with default: "" at line 49, the derived list goes from the 10 hardcoded crates to 17: clickhouse_sink, delta_sink, doris_sink, http_sink, influxdb_sink, influxdb_source, mongodb_sink are new here. Any of those that does not emit lib<crate>.so on x86_64-unknown-linux-gnu / aarch64-unknown-linux-gnu now fails the edge release rather than being skipped.

The hard failure is the right call, the concern is that it is unverified for the 7 additions. Per the PR description the local validation was the docker image build, which is a different job and a different build graph. timeout-minutes: 60 is also unchanged for what is now a 17-crate release build on the standard runners, and the tarball grows accordingly (delta/arrow, iceberg, mongodb, surrealdb closures).

Worth running the Connector plugins job on this branch before merge to confirm all 17 produce a cdylib on both targets and that it fits in the timeout.