Automate zebrad releases

[dconnolly]

In which we track the doing of tasks/automation work to actualize the release processes described in the Release RFC

Use a manually triggered workflow to trigger releases, configuring the release with human input like a version number (maybe, it would be nice to pre-populate this field) and the release notes/changelog update:

A simple example I created: https://github.com/dconnolly/zebra/blob/main/.github/workflows/release.yml

Possible release workflow steps:

• [ ] identify crates that need version bumps based on commits - release-please
• [ ] manually decide if each bump is major/minor/patch
• [ ] manually edit the changelog
• [ ] run cargo-release ?
• [ ] build the release commit
• [ ] upload/link the build artifacts to the github release
• [ ] push release commit to crates.io - cargo-workspaces
• [x] deploy to zebrad-main container instance group on gcloud, this should already happen automatically when the release commit lands on the main branch

The above are pieces we're pretty certain we want/need to do on release. Other things to discuss:

• bump version to next semver, as the in-progress collecting version (this means two commits, the release commit with all the changelog/release notes, and another commit that does the version bumps to start collecting for the new version)

• alerting: internally, on Discord (probably handled fine by our github-notifications channel), on Twitter (either as a Zebra-specific bot, or on the official ZcashFoundation account)

• Debian packages: we can build them and pin them on our GitHub release fine, but what about package repositories? What about HomeBrew (macOS)?

• Docker image release: we create this anyway, do we want to publish it, or a version of it (perhaps without the tracing config endpoint exposed)?

• Signing?

• library releases in concert with the binary release

Links:

https://lib.rs/crates/cargo-workspaces https://github.com/googleapis/release-please

https://rust-cli.github.io/book/tutorial/packaging.html https://github.com/sunng87/cargo-release https://github.blog/changelog/2020-07-06-github-actions-manual-triggers-with-workflow_dispatch https://github.com/BurntSushi/ripgrep/blob/master/.github/workflows/release.yml https://docs.github.com/en/actions/creating-actions/metadata-syntax-for-github-actions#inputs

[yaahc]

I think we might want to consider this a sub-issue of https://github.com/ZcashFoundation/zebra/issues/747, if you agree I'll rename that issue to Tracking Issue: and add this to the bullets there.

[dconnolly]

I think we might want to consider this a sub-issue of #747, if you agree I'll rename that issue to Tracking Issue: and add this to the bullets there.

This is distinct from testing or building as part of continuous integration, this is automating the tasks that are triggered by humans when they fire a release workflow/job consciously.

[dconnolly]

Removing from the 'sync and validate' milestone because that milestone basically corresponds with our first alpha, which is just 'this repo', whereas the first release(s) (binaries, packages, etc) basically correspond to our first major version which will be shortly after our first alpha.

[dconnolly]

Related: https://github.com/ZcashFoundation/zebra/pull/927

[teor2345]

Related: #1063 - Release process RFC.

@dconnolly is there anything in this issue that should be added to the RFC?

[dconnolly]

This is mostly about implementing our release/tagging protocol we ran for our first alpha release, so that it can be repeated reliably by a human triggering a GitHub workflow as part of a team meeting.

[mpguerra]

I wonder if we have a good enough process that we can close this issue or whether we want to go through a few more iterations before we do so

[teor2345]

I wonder if we have a good enough process that we can close this issue or whether we want to go through a few more iterations before we do so

I think we can automate everything except:

• deciding if version bumps are major/minor/patch
• editing the changelog

It would save us a lot of time if we automate as much as possible, because we are doing fortnightly releases.

[teor2345]

This ticket is full of different ideas, which makes it difficult to schedule and prioritise.

Instead, let's open specific tickets for the release automations we need, when we have some experience doing release candidates.