Releases
Distribution
GitHub-native releases with trust material built in.
kubediag releases are cut by GitHub Actions and GoReleaser when a semantic version tag is pushed. The important outcome is not only the binary archive, but the supporting material around it: checksums, signatures, certificates, and SBOMs.
Platform archives
Each release ships archives for Linux amd64/arm64, macOS amd64/arm64, and Windows amd64.
Checksums and signatures
Checksum and cosign artifacts make the release verifiable in environments that care about provenance and supply-chain policy.
SBOMs
Per-archive SBOM output gives downstream consumers dependency visibility without running a second scanning pipeline.
Artifact names
kubediag_linux_amd64.tar.gz
kubediag_linux_arm64.tar.gz
kubediag_darwin_amd64.tar.gz
kubediag_darwin_arm64.tar.gz
kubediag_windows_amd64.zip
checksums.txt
checksums.txt.sig
checksums.txt.pem
Verification flow
Release verification
Treat GitHub Releases as the canonical artifact source.
The release feed is the source of truth for binary download, checksum verification, signature validation, and future packaging integrations.
https://github.com/khvedela/kubediag/releases
Whether you mirror artifacts internally or install directly from GitHub, the verification story should anchor on this release feed.
Packaging status
| Channel | Status |
|---|---|
| GitHub Releases | Available |
| Prebuilt binary archives | Available |
| Checksums, signatures, certificates | Available |
| SBOMs | Available |
| Homebrew tap | Planned |
| Krew index publication | Planned |
Why this matters operationally
For infrastructure tooling, install instructions are not enough. Teams also need to know:
- where the artifact came from
- how to verify it
- whether dependency inventory is published
- which distribution channel is actually authoritative
That is why the docs site treats release trust as a first-class product surface rather than burying it under a short download paragraph.