This repository publishes one crate: hubuum_client. The workspace also contains
the unpublished hubuum_reconcile code generator and the unpublished
e2e_client integration consumer.
Trusted publishing on crates.io only works after a crate has been published once manually. Run this bootstrap only when introducing a new published crate, before creating the release tag that should publish it.
-
Run the local release checks:
./scripts/check-release.sh vX.Y.Z
-
Publish the new crate manually from a clean checkout:
cargo publish -p <new-crate> --locked
-
In crates.io, configure a trusted publisher for the new crate with:
- owner:
terjekv - repo:
hubuum-client-rust - workflow:
release.yml - environment:
release
- owner:
-
Optional but recommended: in GitHub, create a protected
releaseenvironment so publishes can require approval.
-
Confirm that the repository has no open pull requests. Merge or close every open pull request before continuing with the release.
-
Update every direct and transitive dependency to its latest version compatible with the declared MSRV and repository policies. Update manifest constraints where needed, regenerate
Cargo.lock, and runcargo audit,cargo deny check bans licenses sources, and the required workspace checks. The MSRV check must cover every workspace target:cargo +1.88 check --workspace --all-targets --all-features --locked
Do not defer a blocked dependency update until after the release.
-
Update the client manifest version to the next release number.
-
Reconcile generated resource code and commit any reviewed changes:
cargo run -p hubuum_reconcile --locked -- update cargo run -p hubuum_reconcile --locked -- check
-
Set
[package.metadata.hubuum].server-versionandserver-imageto the targeted server release and its immutable image digest. -
Update the required CI image and pinned OpenAPI source to the same server release. Keep scheduled forward-compatibility checks on server
main. -
Add the client/server pair and test evidence to
COMPATIBILITY.md. -
Add a dated
## [x.y.z] - YYYY-MM-DDsection toCHANGELOG.mdthat names the targeted server release. -
Update the crates.io version and compatibility statements in
README.md. -
Run:
./scripts/check-release.sh vX.Y.Z-
Fetch the protected branch and confirm the release commit is its exact current head:
git fetch origin main ./scripts/check-release-provenance.sh HEAD origin/main
-
Push a tag like
vX.Y.Zfrom that verified commit. Do not merge another commit tomainuntil the release workflow has accepted the tag.
The Release GitHub Actions workflow fetches origin/main and rejects a tag
unless its commit is exactly the protected branch head. It validates release
metadata and package contents, then invokes the repository's reusable CI
workflow for the exact tagged commit. Formatting, lint, documentation, unit and
compile tests, every feature combination, MSRV, OpenAPI drift, supply-chain,
public API compatibility, and pinned library plus e2e_client integration
checks must all succeed before trusted publishing can start.
The publish job first checks the registry. After a successful or
already-completed crate publish, the workflow creates or updates the GitHub
Release for the exact tag, uses only that version's dated CHANGELOG.md section
as the release notes, and marks it as Latest. Both publication steps are
idempotent, so a rerun still repeats provenance and required-check evidence
before treating existing crates.io and GitHub releases as successful no-ops.
To repair historical release metadata, manually dispatch the Release
workflow from main with backfill_github_releases enabled. The backfill
creates or updates every stable tagged release from its matching changelog
section and leaves the newest stable tag marked as Latest. This mode does not
publish crates.