Skip to content

ci: release workflow and release guide - #84

Merged
heidari-dev merged 7 commits into
mainfrom
ci/release-workflow
Nov 14, 2026
Merged

heidari-dev merged 7 commits into
mainfrom
ci/release-workflow

Conversation

@heidari-dev

Copy link
Copy Markdown
Owner

Closes #83

What: .github/workflows/release.yml, run by a v* tag push or by hand, and docs/releasing.md.

A tag run builds the .deb, AppImage and a kite tarball (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 writes SHA256SUMS, attests every file with actions/attest-build-provenance, adds a .sigstore.json bundle (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 is vX.Y.Z[-suffix], matches Cargo.toml and the Android versionName, 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-apk job sees the four KITE_* secrets. It runs for tags only, in an environment named release, has no checkout and installs nothing, so no code but the runner's apksigner runs next to the key. Every other job has contents: read; sign adds id-token and attestations, and only publish has contents: write. A missing secret fails a tag run with the secret's name; a dry run never gets the key and ships kite-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, the release environment (tag rule v*, required reviewer) and a v* tag ruleset by hand; docs/releasing.md has 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.lock through 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.

@heidari-dev
heidari-dev merged commit 790f27d into main Nov 14, 2026
16 checks passed
@heidari-dev
heidari-dev deleted the ci/release-workflow branch November 14, 2026 07:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Release workflow

1 participant