Axum: validate multi-platform containers and provide an application publishing workflow #399

Part of #391.

Description

Validate #398's application Docker recipe on linux/amd64 and linux/arm64, then provide a tested publishing workflow recipe for application owners. EdgeZero builds disposable CI application images; Trusted Server and other applications publish their own release artifacts. This issue does not publish an EdgeZero application or base image.

Current implementation on audited main

Existing CI primarily runs native tests on ubuntu-latest plus WASM adapter matrices. There is no application-container architecture matrix or tested image-publishing recipe. The example app is excluded from the root workspace and has a separate lockfile. Existing actionlint/action-ref checks cover new workflows, but the Zizmor scan enumerates files explicitly and must include the new workflow.

The existing build-tool image plan is a different artifact with a single-architecture contract. It does not establish application runtime support on two architectures.

Concrete consumer and ownership

Use Trusted Server's release-tagged EdgeZero Git dependencies, committed Cargo/npm lockfiles, pinned Rust/Node, and JS-before-Rust build as the application-owner example. #398 records exact source references and portable build assumptions. Keep the recipe parameterized for the app's context/Dockerfile/package and registry; don't require Stackpop credentials or deploy an app-owned production configuration in framework CI.

Trusted Server #897 owns its actual registry/release/installer decisions. Any test publication here must use an explicitly authorized disposable destination, not establish a supported public EdgeZero application image.

Proposed solution

1. Add native amd64/arm64 matrix jobs, subject to runner availability. Build and execute the final application image on each target; compilation alone is insufficient. Start with GNU/glibc-compatible builder/runtime images. Treat QEMU as an explicitly labeled fallback, not hidden native evidence.
2. On pull_request, build, run container checks, scan, and retain test artifacts using read-only permissions. No registry login, secrets, privileged pull_request_target execution, or automatic promotion of untrusted PR artifacts.
3. For a trusted downstream release, build/test at the authorized release commit, then hand the exact tested artifacts to a separate publishing job. Do not rebuild after acceptance. Verify digest-preserving artifact transfer/import before relying on that mechanism.
4. Assemble the multi-platform runtime index only after both variants pass. Use least privilege, non-persistent checkout credentials, full action SHAs and pinned/verified base inputs for publication. Validate the workflow with actionlint, shell checks, the action-ref gate, and Zizmor.
5. Show version tags, immutable digest deployment/rollback, source revision labels, SBOM/provenance generation and verification, scan thresholds with reviewed expiring exceptions, retained rollback digests, and security rebuild ownership. Keep destination/token/release policy application-owned.
6. Reuse one set of final-image tests between PR validation and trusted releases. Keep slow application/browser suites in downstream CI rather than copying Trusted Server wholesale into EdgeZero.

Delivery slices and dependencies

A. Architecture preparation: depends on #398's buildable recipe and basic container tests, not completion of every runtime issue. Add both native builds, constrained HTTP/TLS smokes, static/security workflow validation, and artifact handoff checks now. Record unavailable runners or unexecuted publication steps as gaps, not passes.

B. Final runtime acceptance: use accepted PR #275, with #392 lifecycle/readiness and #396 config/storage first, then relevant #393 buffered-body, #394 streaming, #395 outbound, and #397 diagnostics checks. Coordinate rather than duplicate the transport implementation. Preserve HTTP protocol and BestEffort/Unsupported limits.

C. Downstream release adoption: deliver the publishing recipe to Trusted Server's image work. Real application publication/deployment is downstream; EdgeZero must prove its workflow mechanism using a controlled fixture before describing it as tested.

Done when

• Final images built from Axum: scaffold hardened production application Dockerfiles #398's recipe run on linux/amd64 and linux/arm64, with runner/emulation evidence recorded.
• Both images pass the same non-root/read-only-root, HTTP, TLS, and mount checks; runtime readiness/persistence/shutdown acceptance is added when the owning issues land.
• Pull-request execution has no publication authority or deployment secrets.
• A controlled workflow exercise proves the trusted publisher receives the tested artifacts, preserves/verifies their digests, and assembles the intended runtime platform variants without rebuilding.
• The documented downstream publishing path covers SBOM/provenance, source/lock/toolchain traceability, vulnerability policy, public pull where desired, retained digests, and rollback. Any unexercised registry-specific behavior is explicitly labeled.
• Workflow lint/security checks include the new files, and no existing native/WASM gate is weakened.
• Preparation can land independently of final production certification; remaining acceptance gaps are linked to their owners.
• No public EdgeZero application image is required; actual Trusted Server release ownership is linked rather than duplicated.

Related work

#398 packaging; #161 generated workflows; #400 deployment guides; Trusted Server #897. Custom build-tool containers, standalone native CLI releases, and cloud provisioning commands are separate work.

Affected areas

CI / Tooling; Adapter -- Axum; Documentation.

Implementation and relationship tracking

No published implementation PR currently represents this issue. GitHub records #398 as its prerequisite for the buildable recipe. Architecture/publishing preparation remains independent of completing every runtime issue; final runtime acceptance retains the slice B prerequisites above. This issue blocks #400's architecture-backed deployment claims.