fix(docker): make Tentacle images OCI-compliant (FD-492)

[todthomson]

Background

Customer FD-492 (Zendesk 209584, ARUP Laboratories) reported that the octopusdeploy/tentacle Docker image is not OCI compliant: Podman rejects it when it is used as a base image (FROM octopusdeploy/tentacle …).

The root cause is not Dockerfile content and not the Debian 11→12 base-image upgrade (#1218 / EFT-3311) — that PR does not touch the manifest format, and building the old vs new image locally shows no difference. The actual problem is inconsistent/mixed manifest media types produced by the build/push pipeline. Docker tolerates this; strict OCI clients like Podman do not.

What Octopus Server actually does (verified in the OctopusDeploy repo)

The triage note claimed Server "fixed the same issue in Jan 2026." I checked the Server repo history directly and that framing is not accurate. There is no oci-mediatypes/--provenance flag combination anywhere in Server's history (git log -S finds zero hits). Instead, Server builds its Linux image single-architecture (linux/amd64) with the classic Docker builder (DockerTasks.DockerBuild + DockerTasks.DockerPush, nuke-build/Build.DockerImages.cs), producing one self-consistent Docker schema2 manifest with no manifest list and no attestation index. Server avoids the problem by never producing a multi-arch/attestation manifest, rather than by fixing one with flags.

Why this PR uses buildx flags instead of copying Server

The Tentacle Kubernetes agent image is genuinely multi-arch (linux/arm64,linux/amd64) and therefore must be built with buildx and a manifest list — it can't adopt Server's single-arch classic-build approach without dropping arm64. For a multi-arch buildx image, the correct equivalent remedy is to force a single OCI media type and drop the attestation index.

Manifest evidence (verified against the published registry)

octopusdeploy/tentacle:latest (the customer's image) — confirmed two distinct OCI violations:

1. The OCI index mixes manifest formats:

   Platform	Manifest mediaType
   linux/amd64	application/vnd.oci.image.manifest.v1+json (OCI — buildx)
   windows/amd64	application/vnd.docker.distribution.manifest.v2+json (Docker schema2 — classic docker build/push)

   A strict OCI consumer rejects an OCI index that references a Docker-schema2 manifest.

2. Even the linux/amd64 manifest mixes layer media types — application/vnd.docker.image.rootfs.diff.tar.gzip ×4 (inherited debian base layers) + application/vnd.oci.image.layer.v1.tar+gzip ×8 (new layers). This is the literal "mixes two layer format standards", normalized by oci-mediatypes=true.

kubernetes-agent-tentacle:latest (this repo's image) — current published index contains 4 manifests: arm64, amd64, plus two unknown/unknown attestation-manifest entries (buildx provenance). Its per-platform layers are already uniformly OCI, so here the defect is purely the attestation index — removed by disabling default attestations (BUILDX_NO_DEFAULT_ATTESTATIONS=1). (Per-platform layer types verified all-OCI.)

Changes

1. Build the Kubernetes agent image with consistent OCI media types (build/Build.Pack.cs)

   • On push, use --output type=image,oci-mediatypes=true,push=true and BUILDX_NO_DEFAULT_ATTESTATIONS=1 so the whole manifest uses a single OCI media type with no attestation index.
   • The local --load path (used by tests/dev) is unchanged.

2. Modernize image labels across all four Dockerfiles

   • Replace the deprecated org.label-schema.* namespace (retired 2016) with the standard org.opencontainers.image.* annotation keys.
   • Use the SPDX identifier Apache-2.0 for the license.

⚠️ Follow-up required (out of scope for this repo)

The customer-reported image, octopusdeploy/tentacle (docker/linux/Dockerfile), is amd64-only on Linux but published in a multi-platform tag alongside the Windows image, and is built in the TeamCity pipeline, not in this repo's NUKE build. Closing FD-492 for that image requires, in TeamCity: (a) build/push the Linux image with oci-mediatypes=true so its layers are uniformly OCI, and (b) assemble the multi-platform tag so the Windows manifest is also OCI (otherwise the OCI index keeps referencing a Docker-schema2 manifest). This PR fixes the Kubernetes agent image (built here) and the shared label metadata.

Testing notes

• dotnet build build/_build.csproj succeeds.
• Verify the pushed manifest with docker buildx imagetools inspect --raw <tag>: the index should contain only the two platform manifests (no unknown/unknown attestation manifests), and every layer mediaType should be application/vnd.oci.image.layer.v1.tar+gzip. Plus a podman pull / FROM smoke test.

🤖 Generated with Claude Code

---

Note (review follow-up): the attestation switch is standardised on BUILDX_NO_DEFAULT_ATTESTATIONS=1 to match the docker buildx bake step in OctopusDeploy/TeamCity-Configuration#112 (identical across buildx build and bake, covers all default attestations, and avoids a post-PATH CLI flag).

---

OCI annotations (review follow-up): in addition to the Dockerfile LABELs (which set org.opencontainers.image.* on the image config), the k8s agent build now also stamps those annotations onto the image index and each platform manifest via the buildx exporter annotation-index.* / annotation.* options — the spec-preferred location registries/OCI tooling read. Verified locally on a multi-arch build. The linux octopusdeploy/tentacle :latest index is assembled by a separate docker manifest create step (TeamCity-Configuration), so its index annotations are deferred to the manifest-step follow-up (switching to docker buildx imagetools create --annotation).

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
1 out of 2 committers have signed the CLA.

✅ todthomson
❌ Test

---

Test seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}