Build the release. One command produces everything an operator needs and nothing
they do not.
What it produces. A binary for each platform the build already covers, built from a
tagged commit and from nothing else. A checksum file covering every artefact. The
software bill of materials and the third-party notices from the legal milestone.
The notice, the licence and the privacy document alongside the binary. Nothing
else, and specifically no installer, because this board asks nobody to install
anything.
How it behaves. It runs only on a tag, never on a push or a pull request, so a
release cannot be produced by accident. It does not restore any cache, because a
cache is writable by jobs a release must not trust. Its write permissions are
granted on the one job that publishes and nowhere else. It is never cancelled by a
newer run, which is the one place in this repository where the run-cancelling
concurrency used everywhere else would be wrong, and that exception is written at
the workflow rather than left to be noticed.
The build is reproducible enough to be checked. Two runs from the same tag produce
binaries with the same checksums, or the reason they cannot is written down. This
is the difference between a checksum that proves the download arrived intact and one
that proves the download is what the source says it is.
Whether the artefacts are also cryptographically signed depends on the answer to
the question issue and is not decided here. The workflow is written so that adding
signing is one step rather than a redesign.
Done when a tag produces the artefacts listed above, the checksum file covers all
of them, two runs from the same tag produce identical checksums or the reason is
written down, and the workflow passes the audit job already in this repository.
Build the release. One command produces everything an operator needs and nothing
they do not.
What it produces. A binary for each platform the build already covers, built from a
tagged commit and from nothing else. A checksum file covering every artefact. The
software bill of materials and the third-party notices from the legal milestone.
The notice, the licence and the privacy document alongside the binary. Nothing
else, and specifically no installer, because this board asks nobody to install
anything.
How it behaves. It runs only on a tag, never on a push or a pull request, so a
release cannot be produced by accident. It does not restore any cache, because a
cache is writable by jobs a release must not trust. Its write permissions are
granted on the one job that publishes and nowhere else. It is never cancelled by a
newer run, which is the one place in this repository where the run-cancelling
concurrency used everywhere else would be wrong, and that exception is written at
the workflow rather than left to be noticed.
The build is reproducible enough to be checked. Two runs from the same tag produce
binaries with the same checksums, or the reason they cannot is written down. This
is the difference between a checksum that proves the download arrived intact and one
that proves the download is what the source says it is.
Whether the artefacts are also cryptographically signed depends on the answer to
the question issue and is not decided here. The workflow is written so that adding
signing is one step rather than a redesign.
Done when a tag produces the artefacts listed above, the checksum file covers all
of them, two runs from the same tag produce identical checksums or the reason is
written down, and the workflow passes the audit job already in this repository.