Publishing in CI

[Nemo157]

I've recently been looking at revamping my CI setup, which has included publishing in CI since before Rust 1.0 (damn, time really flies). As part of that I finally got round to looking into what it would take to have Travis.CI support it natively, turns out it is pretty trivial so there's now a PR that should hopefully allow publishing via something as simple as

deploy:
  provider: cratesio
  token:
    secure: "<Encrypted API Token>"

(well, once you add all the other configuration you might want like checking you remembered to bump the version number and verifying GPG signed tags you end up with something like this, but that's still slightly nicer than using the script provider).

[epage]

This is awesome! Eventually I was going to look at ways to simplify the release process but this takes care of one of my ideas.

I only have this marked as Question because its dependent on your PR.

[epage]

So here is a question, should your git tag auto-publish the crate or is it best to cargo publish before creating a tag?

There have been a couple of times that my cargo publish has failed. Regular causes

• Extraneous files
• Ran cargo init but need to enter more fields

Both cases are things I see that could happen during someone's CI. The first is an issue on any CI change. The second is only an issue for first-publish. Debugging the first issue on an CI could be a pain though and now you've tagged a commit.

Are there problems with changing the tag? If yes, how bad is it to burn a release number?

Because of this, I've been toying with the idea of doing cargo publish before git push upstream master --tag <X>.<Y>.<Z>.

[Nemo157]

Personally I'm much more in favour of the guarantees provided by publishing through CI. When you have a build log you can point at and say "there, you can see the package being uploaded, you can even see I personally signed this release" it helps with trusting that the crate sources are literally exactly what the git tag says they should be. I'm not sure if I have ever actually published a crate myself.

I really don't consider burning patch versions an issue. I have done it many times in the past when trying to improve little bits of my CI pipelines, it is slightly annoying (and that's part of the reason I'm trying to come up with my personal One True .travis.yml to move all my repositories to) but version numbers are cheap. I have occasionally re-tagged a repository when something went wrong, generally I believe I only did that before the first release made it to crates.io, once something is really published I try to treat the tags as immutable.

One thing that publishing through Travis.CI actually helps you avoid is extraneous files, right before the deploy step they run git stash --all to remove any local changes to the repository. That doesn't mean there aren't things you can do to cause it to fail (I hit the missing metadata issue this evening when working on the deploy provider support), but that major one is removed.

[epage]

Thanks for the insight in your process and reasoning.

[Nemo157]

Also maybe relevant is rust-lang/crates.io#849, if that is ever implemented then you would likely need to do the first publish of a crate manually so that you can then generate a scoped API token to put into CI.

A complication I just remembered about is publishing workspaces of multiple crates. It would hopefully be possible to push the complication into cargo publish --all for verifying which crates have actually changed and need publishing, but until something like that is supported it's probably too much effort to come up with a script to do it reliably.

[epage]

A complication I just remembered about is publishing workspaces of multiple crates.

Workspace best practices are something are also needing investigation. What do people generally do? Is the whole workspace tagged together? Are tags prefixed with the specific crate involved.