Multi-architecture images: verify every platform behind one tag

Operational decision

A document parser runs on both x86 and ARM nodes. Build both variants from one reviewed source revision and inspect the index before promotion. The shell fragment is a read-only manifest inspection; use the approved registry name and digest from the build record. Run malformed-document regression tests on actual nodes of both architectures, then confirm each Pod reports the expected image ID. If a builder used emulation, account for slower compilation and test enough native behavior to catch architecture-specific faults. Keep the old index digest available for rollback and make sure it still resolves to both variants. Never promote a mutable tag alone; two clusters can pull different contents if the tag changes between deployments. When scanning or attesting the build, cover the index and each child artifact according to the chosen tool's model.

docker buildx imagetools inspect registry.internal/parcel/document-parser@sha256:0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef
kubectl get pods -n render -l app=document-parser -o wide
kubectl get pods -n render -l app=document-parser -o yaml

Cost and verification

Two architecture variants increase build time, registry storage, scan work, and test-matrix size. Native builders can reduce emulation overhead but add runner management. One index simplifies deployment references only when its children are complete and verified. A digest pins content, yet a runtime regression on an untested architecture remains possible. Measure startup and parsing latency on each platform before assuming identical performance.

Common Mistakes

• Do not infer ARM behavior from a passing x86 test.
• Do not record only a mutable tag when promoting an image index.
• Do not confuse the index digest with the selected child manifest or runtime image ID.

Connected lessons

• DevOps: delivery, infrastructure, and reliable operations
• Container builds: small runtime, explicit privilege
• Immutable artifacts and release provenance
• Software supply chain: SBOM and provenance at admission
• Dependency patch campaigns: update, test, and prove the running image

Practice and check

• Project: protect a release through failover and capacity pressure
• DevOps release safety decisions

Advanced follow-up

• CI matrix gates: distinguish skipped, canceled, experimental, and passed