Create a CI script for automated releases

[phil-opp]

This automates the cargo publish and the git tag parts of releases. Fixes #277.

After merging this PR, we can issue new releases by changing the version key in the Cargo.toml. The script will automatically detect whether it's a new release by querying the crates.io API. If it's a new release, it will run cargo publish, authenticated as a rust-osdev-autorelease account. It will also create a git tag for the release.

The auth token is stored as an environment secret in the repo settings. I set up some protection rules to ensure that this environment can only be used from the master branch. I also set up a rule that each release run requires an explicit approval from a @rust-osdev/x86_64 team member. We can lift the latter restriction later when we're sure that everything works as intended.

The changelog needs to be updated manually before the release as well. I recommend to use the cargo release tool for this, which is already configured in our Cargo.toml. Just a simple cargo release patch (for non-breaking changes) or cargo release minor (for breaking releases) should be enough to bump the version in the Cargo.toml and update the changelog headings accordingly. These changes can then proposed by opening a pull request against master.

[josephlr]

This is great! Were you able to test this, or should we just try it out for 0.14.4 ?

[phil-opp]

I tested this for some sample releases, e.g. in https://github.com/rust-osdev/x86_64/runs/3101637846?check_suite_focus=true . But yes, I think trying it out for 0.14.4 is a good idea.

[josephlr]

This can be made (slightly) more efficient by querying something like https://crates.io/api/v1/crates/x86_64/0.14.3 directly, and then just checking if the returned JSON has a "version" field, or that version.num is the requested field.

[josephlr]

But the existing solution is also fine, let's see if it works for 0.14.4

[phil-opp]

Good idea! I didn't know about this API endpoint. Is there a complete reference for it somewhere?

[phil-opp]

Ok, so I directly disabled the "require explicit approval" rule because we would need to approve every single CI run on master this way.

[josephlr]

Ok, so I directly disabled the "require explicit approval" rule because we would need to approve every single CI run on master this way.

Seems reasonable, approving each one would be a hassle. I'm wondering if we could do a two-stage thing, where stage one detects if deployment is necessary (and needs no creds), and then stage two actually does the publish/tag.

Good idea! I didn't know about this API endpoint. Is there a complete reference for it somewhere?

Not that I could find, I was just looking though the JSON returned by the top level API, and I saw that endpoint.

[phil-opp]

Seems reasonable, approving each one would be a hassle. I'm wondering if we could do a two-stage thing, where stage one detects if deployment is necessary (and needs no creds), and then stage two actually does the publish/tag.

We could create GitHub releases as a first step, and then use a job that is triggered on releases to do the crates.io publishing. I'm not sure if the two-stage approach would be needed though, since the secrets should only be available within this repo anyway (not on pull requests). Also, I locked it down even further to the master branch, which we cannot push to without approval from someone else.