Documentation
¶
Overview ¶
Command conformance-bundle writes the conformance archive — the published cpybkc-conformance.tar.gz — to a file.
It is the fourth asset a release attaches, and the first that is not a description of an interface but a program somebody runs. It carries the corpus, a digest of the corpus, and cpybkc-conform built for every platform this repository builds it for, under one directory:
cpybkc-conformance/README.md cpybkc-conformance/corpus.sha256 cpybkc-conformance/corpus/... cpybkc-conformance/bin/cpybkc-conform-linux-amd64 cpybkc-conformance/bin/...
Why an archive of binaries, rather than an image ¶
A generator author checking their work has to get the engine and the corpus onto a machine, and until this existed the only route was cloning this repository. The natural next thought is a container image, and it fails a specific and common adopter: an engineer whose builders have no egress and whose images come from an internal mirror with an allowlist, where adding an external image is a ticket with a security review and a named internal owner. Conformance is what an outsider runs once, on a whim, before they are invested — the worst possible place to spend a procurement ticket, and a first-day bounce costs the adoption entirely (#202).
So the offline path is a download and an `--exec`: no registry, no daemon and no image. `--image` is the other door the same program offers, and it is where the properties that make a result believable to somebody else live — no network, a read-only root, a memory and process cap, a wall-clock bound (#203). It is the standard and deliberately not the gate: what an adopter can run on their first afternoon has to be the one that needs nothing.
Why the binaries are in it ¶
The corpus alone is what a third party already had — a set of files with the right answer written down, and nothing that would ask their generator about it. What makes the archive worth downloading is the program on the other side of that question, and a program that has to be compiled first is one that needs a Go toolchain the adopter has no other reason to have.
One archive rather than one per platform, because the whole point is that a person on a machine with no egress can be handed a file. Which platforms are in it is the pipeline's (.dagger/main.go, conformPlatforms), not this command's: it archives every regular file it is given under -bin, so a platform is added there and arrives here without this file changing.
Why the bytes are stable ¶
Every tar field the filesystem could have supplied — modification time, owner, group, and any permission beyond the two modes written here — is a constant, and the entries are emitted in sorted order rather than in the order a directory read happened to return. The gzip layer contributes no timestamp and no original file name for the same reason. What is left is a function of the paths and the contents, so two builds of one commit produce one archive, exactly as internal/tools/ir-protos does for the schema.
That is a property of the *wrapper*. Whether the binaries inside are themselves reproducible is the Go toolchain's, and holds for the same reason the published CLI's does: they are built CGO-free and -trimpath by a container that pins its toolchain from go.mod.
It lives under internal/ for the reason ir-protos does: nothing outside this repository has a reason to run it, and cmd/ is where a shipped command goes.
go run ./internal/tools/conformance-bundle -bin ./bin -o cpybkc-conformance.tar.gz
Source Files