Build and attest release binaries in CI instead of uploading them manually #1513
Release binaries are currently built on a maintainer's machine and uploaded by hand. On v0.2.14 the release was published 2026-07-20, and the four cross-platform inferenced binaries were attached 2026-07-27 — six days later.
gh api repos/gonka-ai/gonka/releases/tags/release/v0.2.15 \
--jq '[.assets[].uploader.type] | unique'
# ["User"] — not github-actions[bot]; same on v0.2.14
There are also no build attestations, so gh attestation verify has nothing to check:
So that someone downloading inferenced has no way to confirm the binary corresponds to any particular commit in this repo. That matters more for inferenced than for most artifacts here, because it's the key-custody tool — inferenced keys add generates the mnemonic, and keys export --unarmored-hex emits the raw private key. Following the OpenBroker flow, that key is then permanently bound to a broker account.
Building the artifacts in Actions and attesting them there would bind each one to a commit and workflow by a signature that can't be produced from a laptop:
permissions:
contents: write
id-token: write
attestations: write
steps:
# ... build release artifacts ...
- uses: actions/attest-build-provenance@v2
with:
subject-path: 'release/*'
For what it's worth, the project already does something stronger than most in this area — devshard_escrow_params.approved_versions pins a governance-voted sha256 for devshardd on-chain. That's a genuine multi-party trust anchor. It just doesn't extend to the binaries end users download.
I asked Claude to look into this and it found this:
The repo does contain a release workflow, .github/workflows/release.yml, but it has never published an artifact. Across the 30 most recent runs (back to 2026-02-20), every success is a no-op — should_release is false, so Issue Release Assets and Publish the Release both report → skipped — and every run that actually attempted a build failed, all with the same error:
It's unmodified ignite scaffolding that was never wired up for this repo's layout. The workflow sets defaults.run.working-directory: ./inference-chain, but that only applies to run: steps, and the build is a uses: step (ignite/cli/actions/cli@main, a Docker action with no inputs). So ignite executes at the workspace root, where there's no go.mod — the module is at inference-chain/go.mod.
Even repaired it wouldn't produce the releases in question. The trigger was narrowed from the scaffold's on: push to on: push: branches: [main], which drops the tag path, so ignite/cli/actions/release/vars always resolves tag_name=latest. It could only ever publish a rolling latest prerelease, never release/v0.2.x.
It also has no arm64 Linux target — the release targets are -t linux:amd64 -t darwin:amd64 -t darwin:arm64 — yet inferenced-linux-arm64.zip ships on both v0.2.14 and v0.2.15. Whatever produced that file, it wasn't CI.
Given it has never worked, can't produce tagged releases by design, and fails on every push to main, deleting it looks more sensible than repairing it. Multi-Platform Build already covers compile verification on PRs.
🔄 Auto-synced from Issue #1513 every hour.