Automate Release process with crates.io Trusted Publishing

[josephlr]

When releasing v0.3.4 (#735), there were a few manual steps that I missed (#736). I also had to manually run cargo publish on my laptop and create the corresponding GitHub release: https://github.com/rust-random/getrandom/releases/tag/v0.3.4

Ideally there should be:

• A check run on PRs (as part of the Workspace workflow) which:
  • ensures CHANGELOG.md is correctly formatted
  • ensures the latest dated release matches the version in Cargo.toml
• A new "Tag" workflow which:
  • Runs on any push to master or backports/*
  • If the Cargo.toml version is not tagged on GitHub yet, tag it
  • Create a corresponding GitHub Release using the notes from CHANGELOG.md.
  • Should be a separate workflow, as only this workflow will have permissions to write tags or releases to GitHub.
  • After this is confirmed to work, we should remove the ability for users to manually/unilaterally create Tags
• A new "Release" workflow which:
  • Runs when pushing a tag like vX.Y.Z
  • Publish the tag to crates.io
  • Should be similar to the example in https://crates.io/docs/trusted-publishing
  • We should probably require some sort of approval for this workflow to run (so it doesn't run by accident)
  • After we've confirmed this workflow works, we should remove the ability for users to manually/unilaterally release versions of this crate..

This should also include updating documentation of how the release process works for this crate (maybe in a CONTRIBUTING.md file).

@newpavlov @dhardy are there any release processes you used in previous projects that worked well?

[dhardy]

No. I understand the interest though and may look into trusted publishing.

[dhardy]

Tagging should be an explicit action in my opinion, not a side effect of bumping the version number.

We thus need:

• CHANGELOG.md validation. Possibly using https://github.com/marketplace/actions/changelog-validator
• crates-io publishing (essentially a copy-paste of the linked workflow for trusted-publishing)
• GitHub release automation. Possibly using https://github.com/marketplace/actions/release-changelog-builder
• Review branch and tag protection rules Require CI to have passed for v* tags (this implies that the commit must have already been pushed); can we also require the tagged commit be merged into master?.

[dhardy]

I will leave CHANGELOG validation: @newpavlov has a clearer idea of how he'd like this to work (currently done by manual review and can't be fully automated anyway).

I have added a status-check for tags; not 100% sure how they work however (from the docs, it sounds like cancelled actions will still be considered complete).

[newpavlov]

I wouldn't say I have "a clearer idea". I just want to adhere to the "Keep A Changelog" format which we declare to follow.