Repository navigation
ci: release workflow and release guide - #84
Merged
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #83
What:
.github/workflows/release.yml, run by av*tag push or by hand, anddocs/releasing.md.A tag run builds the .deb, AppImage and a
kitetarball (Ubuntu 22.04,scripts/package-linux.sh), the Android release APK, and one CycloneDX file for each of kite-cli, kite-desktop and kite-ffi. Then it writesSHA256SUMS, attests every file withactions/attest-build-provenance, adds a.sigstore.jsonbundle (cosign keyless) next to each one, and leaves a draft release with notes from the feat, fix and perf commits. Before any of that it checks that the tag isvX.Y.Z[-suffix], matchesCargo.tomland the AndroidversionName, and is on main. A hyphen in the tag makes a pre-release. "Run workflow" does the same without a tag, makes no release and keeps the files as an artifact.Signing: only the
sign-apkjob sees the four KITE_* secrets. It runs for tags only, in an environment namedrelease, has no checkout and installs nothing, so no code but the runner'sapksignerruns next to the key. Every other job hascontents: read;signadds id-token and attestations, and onlypublishhascontents: write. A missing secret fails a tag run with the secret's name; a dry run never gets the key and shipskite-VERSION-unsigned.apk. I moved signing out of Gradle for this, so there is no change to the Android build. The user adds the keystore, secrets, thereleaseenvironment (tag rulev*, required reviewer) and av*tag ruleset by hand;docs/releasing.mdhas the exact steps. Without them a writer can tag a changed copy of the workflow, which is why they are not optional.Why cargo-cyclonedx: it is the CycloneDX project's own Rust tool, reads
Cargo.lockthrough cargo metadata, and is pinned with--locked. Syft would scan the same lock file and add a binary to trust. The SBOMs cover the Rust code only, not the Gradle dependencies. No new action besides attest-build-provenance and cosign-installer, both pinned by SHA.Scorecard: the Signed-Releases check looks for signature or provenance files among the release assets; the Sigstore bundles are those. Its Packaging check only recognises registry publishing workflows, so I do not expect it to change.
How I tested it: CI now builds the unsigned release APK on every pull request. the release workflow was run from this branch (no tag, no release); the result is in a comment below.