Production builds
A deployable carries a small build stamp, not its manifest. The stamp
holds the build id, the commit, whether the tree was modified, the
compiler version, the deployable and the target. Every log event carries
it. Each fault site carries its .jadpo file and line as a constant, so
events already show .jadpo frames
(Errors point at the .jadpo line).
- The manifest is rebuilt, not shipped. Builds are deterministic
(Tooling), so
jadpo incidentbuilds the event's commit, checks that the build id matches, and caches the result. Nothing is uploaded or archived.jadpofetches and runs the exact compiler version the stamp names, asrustupinstalls a pinned toolchain, so an old build can always be rebuilt. - No endpoint. The deployed app reveals nothing about its structure. This also works for a worker with no HTTP surface.
- Native and Wasm alike. Nothing depends on debug information or
unwinding: Rust Workers abort on panic with no stack, so the path comes
from the runtime's own spans. On Workers the stamp is logged beside
CF_VERSION_METADATA, so the platform's version and the Jadpo build can be joined. - Deploy only commits that stay in history, on the default branch or a tag. A build from a modified tree is marked as such, and can be explained only from that exact tree.
jadpo incident isn't built yet (What is built).
Markdown for agents: /docs/production-builds.md.Built from Jadpo main at a707efb.