Automate infrastructure for cutting releases

[sunshowers]

It would be really nice if we had automated infra that would let someone push a tag, then automatically cut a release and push to crates.io based on that.

I've used this pattern before, which involves providing a CARGO_REGISTRY_TOKEN as an environment secret.

https://github.com/oxidecomputer/cancel-safe-futures/blob/main/.github/workflows/release.yml

[ahl]

I've found that almost every release requires some manual intervention, in particular curating change log notes. I use cargo-release to do the actual publishing bits and that's worked out pretty well. When you say that this would be really nice, are you envisioning some more frequent release cadence or something?

[sunshowers]

My initial motivation for the issue was: we ran into an issue with omicron + propolis where we had two copies of progenitor floating around (oxidecomputer/propolis#654) -- one referring to the main branch, and one pinned to v0.5.0. We were discussing how it would be nice to have frequent releases to crates.io and always use that -- which led me to try and figure out what it would take to get a progenitor release out.

Somehow I thought I'd written all this out, but apparently I completely missed including this information while filing the issue yesterday -- sorry about that!

---

The release automation grabs the notes from a changelog file (which is required to be in Markdown because it gets pasted into the GitHub release notes). In fact, the release job fails if there are no changelog notes. I do use cargo release to create a tag and push it as well.

For nextest, the process I use is documented here. An example release is here.

Another benefit of release automation is some degree of rigor in our releases. For example, many open source projects neglect to push tags, or even create them, corresponding to their releases. This isn't a problem for progenitor, but can potentially be one in the future if we scale up the release process.

The automated process necessarily requires that a tag be pushed. It would also let us define an allowlist of who can push tags, which can be "all Oxide employees" or narrower than that.

RFD 409, which is in prediscussion at the moment, covers some of this. (I really should follow up on bringing it into discussion soon...)

[sunshowers]

Somehow I thought I'd written all this out, but apparently I completely missed including this information while filing the issue yesterday -- sorry about that!

Turns out I had written all this out, but the tab it was in crashed, and my brain didn't realize that the issue I did post was incomplete. Sorry!

[ahl]

No problem; my point about the change log was not extracting data from it, but manually adding data to it--people (me) aren't always great at updating it with every commit. If you'd like a new release, it's not much work for me to do that.

[sunshowers]

Got it! Do you think you could make a new release soon? Thank you :)

[ahl]

Sure thing!