Skip to content

crate-publishing.md

Latest commit

 

History

History
34 lines (24 loc) · 3.56 KB

crate-publishing.md

File metadata and controls

34 lines (24 loc) · 3.56 KB

Publishing workspace dependencies

Rationale re: versioning

We publish the majority of our workspace dependencies (essentially everything in the repo aside from binaries, smart contracts, and some internal tooling) to crates.io.

In order to make this easy to maintain, the versions of these workspace dependencies and the nym-sdk crate are kept in sync.

This version is defined in the [workspace.package] section of the root monorepo Cargo.toml file. Each of the workspace dependencies have their paths and versions (this has to be individually defined at the moment per-dependency, this version needs to stay the same as the workspace.package version) defined in the [workspace.dependencies] section of the root monorepo Cargo.toml file.

When Developing

If you add a workspace dependency to the SDK when developing, make sure to add this to the workspace dependencies in the root monorepo Cargo.toml.

Check local publication

# List crates to publish
cargo workspaces list

# Dry run locally - check for compilation or other problems
cargo workspaces publish --no-git-commit --dry-run

CI

There are several workflows that should be run in the following order:

  • ci-crates-publish-dry-run: run this first! This is a remote dry-run on a runner. This greps for any errors that would be a problem when we're not dry-running. It doesn't catch all errors, as dry-run has a known issue where, assuming that 2 new crates are being uploaded, and crate B relies on crate A, if crate A isn't on crates.io (which it won't be, since you're dry-running publication), then since cargo workspaces publish only checks for available versions on crates.io, it will error. We don't want the CI to fail in that case.
  • ci-crates-version-bump: this bumps the versions of the workspace + dependencies to the passed version, and then commits the change. This is its own CI job so that we don't get into sticky situations whereby the version bump + commit happens, but the publication step fails.
  • ci-crates-publish: this publishes the crates. So long as you're not uploading more than 5 new crates, pass 60 as the publish_interval. This is to get around crates.io rate limiting. Pass the Github handle of whoever should be the backup author of the crate for security redundency (see the section below) as the second arg.

There is also ci-crates-publish-resume which is there in case a publication run fails and needs to be restarted part way through the list of unbumped/unpublished crates. Pass the previously bumped/published crate in the list output of cargo workspaces list

Crates.io Authors

Since Github teams have limited ownership / mod rights of crates, and we cannot create a CARGO_REGISTRY_TOKEN on behalf of the Nym Github org. As such, we are currently using personal cargo tokens generated by team members (currently Max), and adding the Nym Github org as an owner in the CI job.

However, since the Github org cannot add or modify owners, are also adding a second user author as a redundency, on the offchance that Max loses access to his Crates.io / Github account, gets struck by lightning, etc. This is the author passed as the second argument to the ci-crates-publish CI, and if none is passed, defaults to https://github.com/jstuczyn since he is the Github org owner.

Authors can also be changed by running scripts/add-crates-owners.sh.