feat: thread --version into the image build as PLT_DEPLOYMENT_ID

[marcopiraccini]

desk deploy -d <dir> -v <version> built the image and then labelled the workload plt.dev/version=<version>, but never told the build what that version was. This passes it through as --build-arg PLT_DEPLOYMENT_ID=<version>.

Query-string skew protection needs one value in three places at once: baked into the client assets as ?dpl=<id> at build time, set as plt.dev/version on the workload, and therefore used as the gateway's match key. --version is that value, so it has to reach the build as well as the deploy.

Without this the failure is silent, which is why it is worth fixing rather than documenting. The image builds fine, the workload deploys fine, and the app runs fine. But its assets carry no ?dpl, so ICC sees a version that was not built with its own id, correctly refuses to emit a routing rule for it, and the app simply has no skew protection. Nothing errors.

lib/registry.js#buildFromDirectory already accepted a buildArgs option; nothing ever populated it.

Deploying without --version is unchanged, and an application whose Dockerfile does not declare the matching ARG PLT_DEPLOYMENT_ID= ignores the build arg.

Related

• platformatic/icc-3#975 implements the query routing this feeds.
• Add skew protection routing mode to Helm chart helm#63 exposes the cluster routing mode.
• feat: bake deployment IDs into framework builds platformatic#5050 (merged, v3.66.0) does the build-time stamping.

Verified end to end on a k3d cluster: desk deploy -v <id> now produces an image whose ENV carries PLT_DEPLOYMENT_ID and whose built assets carry ?dpl=<id>, and requests carrying that query reach that version's pod.

[mcollina]

lgtm

[mcollina]

lgtm