Repository navigation
ci(release): drive releases with release-please, held below 1.0 (LAB-5117) - #8
Conversation
…5117) Every push to main runs release-please (rust release type, bump-minor-pre-major, so a breaking change bumps the minor version while the crate is below 1.0). Merging its release PR creates the tag and GitHub Release; the same workflow run then tests, builds, attests and uploads the binaries and publishes the crate. Tags created by the App do not trigger workflows, so the release no longer runs on a tag push. The README's verify command also pins --source-ref refs/heads/main.
Code Review Completed! 🔥The code review was successfully completed based on your current configurations. Kody Guide: Usage and ConfigurationInteracting with Kody
Providing Context (Files & MCPs)Add these hints in your PR description (or a comment) to unlock deeper checks:
Current Kody ConfigurationReview OptionsThe following review options are enabled or disabled:
|
…5117) Re-running every job after a failed release finds the release already created, so release-please reports no new release and the build jobs skip. A workflow_dispatch on main with the release tag now rebuilds, re-attests and re-uploads that release and retries the crates.io publish. The tag must name a release version on main.
Code Review Completed! 🔥The code review was successfully completed based on your current configurations. Kody Guide: Usage and ConfigurationInteracting with Kody
Providing Context (Files & MCPs)Add these hints in your PR description (or a comment) to unlock deeper checks:
Current Kody ConfigurationReview OptionsThe following review options are enabled or disabled:
|
…ch (LAB-5117) check now checks out refs/tags/<tag>, so a branch with the tag's name is never built, and outputs the commit it verified; build and publish check out that commit, so moving the tag after the check changes nothing. On a dispatch the release-please steps skip, so a release created mid-dispatch is not left without binaries. The release PR is assigned through the REST API, which an App token can call.
Code Review Completed! 🔥The code review was successfully completed based on your current configurations. Kody Guide: Usage and ConfigurationInteracting with Kody
Providing Context (Files & MCPs)Add these hints in your PR description (or a comment) to unlock deeper checks:
Current Kody ConfigurationReview OptionsThe following review options are enabled or disabled:
|
|
Verification of the first release, v0.1.0, built by Release run 37159870532 from
The unpacked binary's SHA-256 is crates.io records |
Releases now go through release-please, and the version stays below 1.0.
rustrelease type, same changelog sections as the other CacheKit SDKs) runs on every push tomainand keeps a release PR open with the next version and changelog.bump-minor-pre-majoris on, so a breaking change bumps the minor version while the crate is below 1.0. The first release is0.1.0: the Rust strategy's initial version. The manifest starts at0.0.0.--source-ref refs/heads/main, so an attestation only passes if the release workflow ran frommain.Needs the
APP_IDandAPP_PRIVATE_KEYrepository secrets for the release App before merge; without them the release-please job fails on every push tomain.Closes LAB-5117