Skip to content

Automate release with pipelines #3933

@KaloyanTanev

Description

@KaloyanTanev

🎯 Problem to be solved

Currently we do all our tagging upon release manually. This is really error prone. If we create pipelines that are with manual trigger it would be much easier.

🛠️ Proposed solution

In the steps below LATEST_MAJOR/LATEST_MINOR/LATEST_PATCH is the latest stable released major/minor/patch version. git does not recognise stable versus pre-release/draft as github does, meaning some checks might need to be done to find the one (i.e.: latest version that does not have -rc in it).

Minor

"Minor Release - Initiate" pipeline:

  • Create a new branch main-v<LATEST_MAJOR>.<LATEST_MINOR + 1>, based on main.
  • Create a new branch obol-gh-actions/bump-version-to-v<LATEST_MAJOR>.<LATEST_MINOR + 1>-version, based on main-v<LATEST_MAJOR>.<LATEST_MINOR + 1>.
  • Checkout to obol-gh-actions/bump-version-to-v<LATEST_MAJOR>.<LATEST_MINOR + 1>-version.
  • Update version/version.go line 18 from var version = "<FULL_VERSION>-dev" to var version = "<FULL_VERSION>-rc". Commit and push the change.
  • Open PR from obol-gh-actions/bump-version-to-v<LATEST_MAJOR>.<LATEST_MINOR + 1>-version towards main-v<LATEST_MAJOR>.<LATEST_MINOR + 1>. This one can be approved and merged right away from a protocol dev.

"Minor Release - Tag new release candidate" pipeline:

  • Checkout to main-v<LATEST_MAJOR>.<LATEST_MINOR + 1> branch (realistically the one we have created in step 1 in "Minor Release - Initiate").
  • Find latest release candidate tag of v<LATEST_MAJOR>.<LATEST_MINOR + 1>. If release candidate is found bind it to variable LATEST_RC, if not, set LATEST_RC to 0.
  • Tag a new version v<LATEST_MAJOR>.<LATEST_MINOR + 1>.0-rc<LATEST_RC + 1>.

In case the first release candidate is not deemed successful, devs should manually create PRs towards main-v<LATEST_MAJOR>.<LATEST_MINOR + 1> branch. Fixes are initially introduced into the main branch. New branches based on the main-v<LATEST_MAJOR>.<LATEST_MINOR + 1> branch are created and commits are cherry-picked from main. Changes are merged to main-v<LATEST_MAJOR>.<LATEST_MINOR + 1>. Pipeline "Minor Release - Tag new release candidate" is re-run until a release candidate is deemed successful.

"Minor Release - Tag full release" pipeline:

  • Create a new branch obol-gh-actions/bump-version-to-v<LATEST_MAJOR>.<LATEST_MINOR + 1>-version-stable, based on main-v<LATEST_MAJOR>.<LATEST_MINOR + 1>.
  • Checkout to obol-gh-actions/bump-version-to-v<LATEST_MAJOR>.<LATEST_MINOR + 1>-version-stable.
  • Update version/version.go line 18 from var version = "<FULL_VERSION>-rc" to var version = "<FULL_VERSION>".
  • Open PR from obol-gh-actions/bump-version-to-v<LATEST_MAJOR>.<LATEST_MINOR + 1>-version-stable towards main-v<LATEST_MAJOR>.<LATEST_MINOR + 1>. This one can be approved and merged from a protocol dev once this pipeline is deemed successful.
  • Create a new branch obol-gh-actions/bump-version-to-v<LATEST_MAJOR>.<LATEST_MINOR + 2>-dev, based on main.
  • Update version/version.go line 18 from <LATEST_MAJOR>.<LATEST_MINOR + 1>-dev to <LATEST_MAJOR>.<LATEST_MINOR + 2>-dev.
  • Open PR from obol-gh-actions/bump-version-to-v<LATEST_MAJOR>.<LATEST_MINOR + 2>-dev towards main. This one can be approved and merged from a protocol dev once this pipeline is deemed successful.
  • Checkout to main-v<LATEST_MAJOR>.<LATEST_MINOR + 1>.
  • Tag a new version v<LATEST_MAJOR>.<LATEST_MINOR + 1>.0.

Patch

"Patch Release - Initiate" pipeline:

  • Checkout to main-v<LATEST_MAJOR>.<LATEST_MINOR> branch.
  • Open PR from obol-gh-actions/bump-version-to-v<LATEST_MAJOR>.<LATEST_MINOR>-rc-<LATEST_PATCH + 1> towards main-v<LATEST_MAJOR>.<LATEST_MINOR>. This one can be approved and merged right away from a protocol dev.

"Patch Release - Tag new release candidate" pipeline:

  • Checkout to main-v<LATEST_MAJOR>.<LATEST_MINOR> branch.
  • Find latest release candidate tag of v<LATEST_MAJOR>.<LATEST_MINOR>.<LATEST_PATCH + 1>. If release candidate is found bind it to variable LATEST_RC, if not, set LATEST_RC to 0.
  • Tag a new version v<LATEST_MAJOR>.<LATEST_MINOR>.<LATEST_PATCH + 1>-rc<LATEST_RC + 1>.

In case the first release candidate is not deemed successful, devs should manually create PRs towards main-v<LATEST_MAJOR>.<LATEST_MINOR> branch. Fixes are initially introduced into the main branch. New branches based on the main-v<LATEST_MAJOR>.<LATEST_MINOR> branch are created and commits are cherry-picked from main. Changes are merged to main-v<LATEST_MAJOR>.<LATEST_MINOR>. Pipeline "Patch Release - Tag new release candidate" is re-run until a release candidate is deemed successful.

"Patch Release - Tag full release" pipeline:

  • Create a new branch obol-gh-actions/bump-version-to-v<LATEST_MAJOR>.<LATEST_MINOR>.<LATEST_PATCH + 1>-version-stable, based on main-v<LATEST_MAJOR>.<LATEST_MINOR>.
  • Checkout to obol-gh-actions/bump-version-to-v<LATEST_MAJOR>.<LATEST_MINOR>.<LATEST_PATCH + 1>-version-stable.
  • Update version/version.go line 18 from var version = "<FULL_VERSION>-rc" to var version = "<FULL_VERSION>".
  • Open PR from obol-gh-actions/bump-version-to-v<LATEST_MAJOR>.<LATEST_MINOR>.<LATEST_PATCH + 1>-version-stable towards main-v<LATEST_MAJOR>.<LATEST_MINOR>. This one can be approved and merged from a protocol dev once this pipeline is deemed successful.
  • Checkout to main-v<LATEST_MAJOR>.<LATEST_MINOR>.
  • Tag a new version v<LATEST_MAJOR>.<LATEST_MINOR>.<LATEST_PATCH + 1>.

Consider adding those to (L)CDVN as well.

Metadata

Metadata

Labels

protocolProtocol Team tickets

Type

No type

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions