Feature: Use release-plz and cargo-dist for making the release procedure easier

[simonsan]

Pre-submission checks

• I am not reporting a bug (crash, false positive/negative, etc). These must be filed via the bug report template.
• I have looked through the open issues for a duplicate request.

What's the problem this feature will solve?

Releasing early and often is complicated and annoying, especially when it comes to CLI.

Describe the solution you'd like

You can use https://release-plz.ieni.dev/ for a release-pr with changes and checking for breaking API changes.

And you can (or should, for building binaries for your users to download) use https://github.com/axodotdev/cargo-dist which can generate you an automatic pipeline for your tool.

Additional context

I can help you with setting it up, if you want to. Cheers.

[woodruffw]

Thanks for the issue @simonsan!

I'm interested in these kind of release automation tools, but I don't think this project is the point (in terms of maturity or release complexity) where one is currently needed.

(For reference, to do a release, all I currently need to do is push a tag and run gh release create. I consider that simple enough, for now.)

I'll leave this open for future discussion.

[simonsan]

Hmm, I think building binaries, would be nice though 🤔 so people don't need to build them with cargo themselves

[woodruffw]

Hmm, I think building binaries, would be nice though 🤔 so people don't need to build them with cargo themselves

I understand, but I'd prefer downstream distributions do this for the time being -- this project is still in beta and pre-built binaries are not an immediate priority of mine, especially since the cargo building + caching flow is pretty smooth within GitHub Actions.

[cedws]

Any chance you would reconsider your position on this?

We are currently using Zizmor in CI via uv which isn't ideal and makes me feel less comfortable from a supply chain security POV than pulling binaries from GitHub Releases would. Is there something I can help with to make this happen?

[woodruffw]

Any chance you would reconsider your position on this?

My plan is to reconsider/re-evaluate here as part of the 1.0 burndown 🙂 -- I'll likely end up using cargo dist at the bare minimum.

We are currently using Zizmor in CI via uv which isn't ideal and makes me feel less comfortable from a supply chain security POV than pulling binaries from GitHub Releases would. Is there something I can help with to make this happen?

Could you elaborate on your concerns here? I've been doing "supply chain"-type security stuff for a bit now, and I think pulling a binary from PyPI is roughly equivalent to pulling the same binary from GitHub, given that both accounts/projects are controlled by the same identity (me). In practice PyPI's immutability guarantees are actually stronger than GitHub's, both at the artifact (file) and project (tag/release) level.

(I agree that pulling from PyPI isn't ideal in the sense that it's a wonky distribution mechanism for a Rust binary.)

[cedws]

uv/PyPi is opaque and additional attack surface. I have a lot of issues with the Python packaging landscape, and I don't necessarily trust PyPi as much as I trust GitHub.

[woodruffw]

OK. This is something that will likely be addressed with 1.0; in the mean time, you can hash-pin from PyPI if you're concerned about the attack surface or supply-chain risks.

[woodruffw]

Moved this to a discussion topic for ongoing conversation -- I'd love to hear some thoughts/opinions from active users!

[funnelfiasco]

In general (and with a bias as a long-time Fedora packager), I prefer downstream binaries since they are easy to update in one fell swoop (e.g. dnf update or brew upgrade) and are generally intended to work with the rest of the packages on my system.

[simonsan]

cargo-dist builds brew packages and creates a tap for you in a separate repository, for example. https://opensource.axo.dev/cargo-dist/book/installers/index.html

These are the installers, that are created, with an own updater, where you can update to a new version of your tool:

Currently supported installers include:

shell: a shell script that fetches and installs executables (for curl | sh)
powershell: a powershell script that fetches and installs executables (for irm | iex)
npm: an npm project that fetches and runs executables (for npx)
homebrew: a Homebrew formula that fetches and installs executables
msi: a Windows msi that bundles and installs executables

[simonsan]

Building a formula is pretty straight-forward, but publishing it requires you to create a your own Homebrew tap (package repository), because the core Homebrew tap does not accept prebuilt binaries from third parties. This sounds hard, but surprisingly it's not: you need to make a repository named "homebrew-tap" under your GitHub org or user, and get a GitHub API token to push to it. dist will manage the contents of the repo for you.

src.: https://opensource.axo.dev/cargo-dist/book/installers/homebrew.html

[woodruffw]

I'm not sold on the value of release-plz in this case, but I'm going to start looking at cargo-dist in the coming days.

[simonsan]

Release-plz makes the overall release process easier by determining if there are breaking changes via semver-checks, choosing the right version number and generating a changelog via cargo-cliff. Then it opens a PR dor the release for you to review. This is the value it provides.

[woodruffw]

I appreciate that you feel strongly about its value, but I'm not going to yakshave about it any more -- zizmor doesn't have a semver surface per se (both because it's a CLI and because it's in beta), and I already have changelog generation configured.

[simonsan]

I appreciate that you feel strongly about its value, but I'm not going to yakshave about it any more -- zizmor doesn't have a semver surface per se (both because it's a CLI and because it's in beta), and I already have changelog generation configured.

I don't feel strongly about it, I'm giving you relevant information to make an informed decision.