diff --git a/.github/ISSUE_TEMPLATE/release.md b/.github/ISSUE_TEMPLATE/release.md new file mode 100644 index 000000000000..0883d5df3d05 --- /dev/null +++ b/.github/ISSUE_TEMPLATE/release.md @@ -0,0 +1,113 @@ +--- +title: Polkadot {{ env.VERSION }} Release checklist +--- +# Release Checklist + +This is the release checklist for Polkadot {{ env.VERSION }}. **All** following +checks should be completed before publishing a new release of the +Polkadot/Kusama/Westend runtime or client. The current release candidate can be +checked out with `git checkout {{ env.VERSION }}` + +### Runtime Releases + +- [ ] Verify [`spec_version`](#spec-version) has been incremented since the + last release for any native runtimes from any existing use on public + (non-private/test) networks. +- [ ] Verify [new migrations](#new-migrations) complete successfully, and the + runtime state is correctly updated. +- [ ] Verify previously [completed migrations](#old-migrations-removed) are + removed. +- [ ] Verify pallet and [extrinsic ordering](#extrinsic-ordering) has stayed + the same. Bump `transaction_version` if not. +- [ ] Verify new extrinsics have been correctly whitelisted/blacklisted for + [proxy filters](#proxy-filtering). +- [ ] Verify [benchmarks](#benchmarks) have been updated for any modified + runtime logic. +- [ ] Verify [Polkadot JS API](#polkadot-js) are up to date with the latest + runtime changes. + +### All Releases + +- [ ] Check that the new client versions have [run on the network](#burn-in) + without issue for 12 hours. +- [ ] Check that a draft release has been created at + https://github.com/paritytech/polkadot/releases with relevant [release + notes](#release-notes) +- [ ] Check that [build artifacts](#build-artifacts) have been added to the + draft-release + +## Notes + +### Burn In + +Ensure that Parity DevOps has run the new release on Westend, Kusama, and +Polkadot validators for at least 12 hours prior to publishing the release. + +### Build Artifacts + +Add any necessary assets to the release. They should include: + +- Linux binary +- GPG signature of the Linux binary +- SHA256 of binary +- Source code +- Wasm binaries of any runtimes + +### Release notes + +The release notes should list: + +- The priority of the release (i.e., how quickly users should upgrade) +- Which native runtimes and their versions are included +- The proposal hashes of the runtimes as built with + [srtool](https://gitlab.com/chevdor/srtool) +- Any changes in this release that are still awaiting audit + +The release notes may also list: + +- Free text at the beginning of the notes mentioning anything important + regarding this release +- Notable changes (those labelled with B[1-9]-* labels) separated into sections + +### Spec Version + +A runtime upgrade must bump the spec number. This may follow a pattern with the +client release (e.g. runtime v12 corresponds to v0.8.12, even if the current +runtime is not v11). + +### New Migrations + +Ensure that any migrations that are required due to storage or logic changes +are included in the `on_runtime_upgrade` function of the appropriate pallets. + +### Old Migrations Removed + +Any previous `on_runtime_upgrade` functions from old upgrades must be removed +to prevent them from executing a second time. + +### Extrinsic Ordering + +Offline signing libraries depend on a consistent ordering of call indices and +functions. Compare the metadata of the current and new runtimes and ensure that +the `module index, call index` tuples map to the same set of functions. In case +of a breaking change, increase `transaction_version`. + +Note: Adding new functions to the runtime does not constitute a breaking change +as long as they are added to the end of a pallet (i.e., does not break any +other call index). + +### Proxy Filtering + +The runtime contains proxy filters that map proxy types to allowable calls. If +the new runtime contains any new calls, verify that the proxy filters are up to +date to include them. + +### Benchmarks + +Run the benchmarking suite with the new runtime and update any function weights +if necessary. + +### Polkadot JS + +Ensure that a release of [Polkadot JS API]() contains any new types or +interfaces necessary to interact with the new runtime. diff --git a/.github/workflows/publish-draft-release.yml b/.github/workflows/publish-draft-release.yml index 41e797196bcb..f091a177f508 100644 --- a/.github/workflows/publish-draft-release.yml +++ b/.github/workflows/publish-draft-release.yml @@ -3,7 +3,8 @@ name: Publish draft release on: push: tags: - - v**.**.** + # Catches v1.2.3 and v1.2.3-rc1 + - v[0-9]+.[0-9]+.[0-9]+* jobs: build-runtimes: @@ -99,19 +100,6 @@ jobs: release_name: Polkadot ${{ github.ref }} body_path: ./release_text.md draft: true - - post_to_matrix: - runs-on: ubuntu-latest - needs: publish-draft-release - steps: - - name: Internal polkadot channel - uses: s3krit/matrix-message-action@v0.0.3 - with: - room_id: ${{ secrets.INTERNAL_POLKADOT_MATRIX_ROOM_ID }} - access_token: ${{ secrets.MATRIX_ACCESS_TOKEN }} - message: "**New version of polkadot tagged**: ${{ github.ref }}
Gav: Draft release created: ${{ needs.publish-draft-release.outputs.release_url }}" - server: "matrix.parity.io" - publish-runtimes: runs-on: ubuntu-latest needs: ['publish-draft-release'] @@ -141,3 +129,15 @@ jobs: asset_path: ./${{ matrix.runtime }}_runtime.compact.wasm asset_name: ${{ matrix.runtime }}_runtime-v${{ steps.get-runtime-ver.outputs.runtime_ver }}.compact.wasm asset_content_type: application/wasm + + post_to_matrix: + runs-on: ubuntu-latest + needs: publish-draft-release + steps: + - name: Internal polkadot channel + uses: s3krit/matrix-message-action@v0.0.2 + with: + room_id: ${{ secrets.INTERNAL_POLKADOT_MATRIX_ROOM_ID }} + access_token: ${{ secrets.MATRIX_ACCESS_TOKEN }} + message: "**New version of polkadot tagged**: ${{ github.ref }}
Gav: Draft release created: ${{ needs.publish-draft-release.outputs.release_url }}" + server: "matrix.parity.io" diff --git a/.github/workflows/release-candidate.yml b/.github/workflows/release-candidate.yml new file mode 100644 index 000000000000..acbd7dbabeba --- /dev/null +++ b/.github/workflows/release-candidate.yml @@ -0,0 +1,57 @@ +name: Release-candidate automation +on: + push: + branches: + - release-v[0-9]+.[0-9]+.[0-9]+ +jobs: + tag_rc: + runs-on: ubuntu-latest + steps: + - uses: actions/checkout@v2 + with: + fetch-depth: 0 + - id: compute_tag + name: Compute next rc tag + shell: bash + run: | + # Get last rc tag if exists, else set it to {version}-rc1 + version=${GITHUB_REF#refs/heads/release-} + echo "$version" + echo "::set-output name=version::$version" + git tag -l + last_rc=$(git tag -l "$version-rc*" | sort -V | tail -n 1) + if [ -n "$last_rc" ]; then + suffix=$(echo "$last_rc" | grep -Eo '[0-9]+$') + echo $suffix + ((suffix++)) + echo $suffix + echo "::set-output name=new_tag::$version-rc$suffix" + echo "::set-output name=first_rc::false" + else + echo "::set-output name=new_tag::$version-rc1" + echo "::set-output name=first_rc::true" + fi + - name: Apply new tag + uses: tvdias/github-tagger@v0.0.2 + with: + # We can't use the normal GITHUB_TOKEN for the following reason: + # https://docs.github.com/en/actions/reference/events-that-trigger-workflows#triggering-new-workflows-using-a-personal-access-token + # RELEASE_BRANCH_TOKEN requires public_repo OAuth scope + repo-token: "${{ secrets.RELEASE_BRANCH_TOKEN }}" + tag: ${{ steps.compute_tag.outputs.new_tag }} + - id: create-issue + uses: JasonEtco/create-an-issue@v2 + # Only create the issue if it's the first release candidate + if: steps.compute_tag.outputs.first_rc == 'true' + env: + GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} + BRANCH: ${{ steps.compute_tag.outputs.version }} + with: + filename: .github/ISSUE_TEMPLATE/release.md + - uses: s3krit/matrix-message-action@v0.0.2 + if: steps.create-issue.outputs.url != '' + with: + room_id: ${{ secrets.INTERNAL_POLKADOT_MATRIX_ROOM_ID }} + access_token: ${{ secrets.MATRIX_ACCESS_TOKEN }} + server: "matrix.parity.io" + message: "Release process for polkadot ${{ steps.compute_tag.outputs.version }} has been started. Tracking issue: ${{ steps.create-issue.outputs.url }}" diff --git a/RELEASE.md b/RELEASE.md index 0d9364a82861..e0e219ad1a57 100644 --- a/RELEASE.md +++ b/RELEASE.md @@ -1,97 +1,45 @@ -# Release Checklist - -The following checks should be completed before publishing a new release of the -Polkadot/Kusama/Westend runtime or client. - -### Runtime Releases - -The following should be done *prior* to tagging the potential release. Upon -completion, tag the commit and proceed with the [All Releases](#all-releases) steps. - -- [ ] List any [native runtime](#native-runtimes) versions associated with the release. -- [ ] Has incremented [`spec_version`](#spec-version) for any native runtimes from any existing use on public (non-private/test) networks. -- [ ] Verify [new migrations](#new-migrations) complete successfully, and the runtime state is - correctly updated. -- [ ] Verify previously [completed migrations](#old-migrations-removed) are removed. -- [ ] Verify pallet and [extrinsic ordering](#extrinsic-ordering) has stayed the same. Bump - `transaction_version` if not. -- [ ] Verify new extrinsics have been correctly whitelisted/blacklisted for - [proxy filters](#proxy-filtering). -- [ ] Verify [benchmarks](#benchmarks) have been updated for any modified runtime logic. -- [ ] Verify [Polkadot JS API](#polkadot-js) are up to date with the latest runtime changes. - -### All Releases - -- [ ] Check that the new client versions have [run on the network](#burn-in) without issue for 12 - hours. -- [ ] Check that a draft release has been created at https://github.com/paritytech/polkadot/releases with relevant [release notes](#release-notes) -- [ ] Check that [build artifacts](#build-artifacts) have been added to the draft-release -- [ ] Check that you have updated the Cargo.toml version. - -## Notes - -### Burn In - -Ensure that Parity DevOps has run the new release on Westend, Kusama, and Polkadot validators for -at least 12 hours prior to publishing the release. - -### Build Artifacts - -Add any necessary assets to the release. They should include: - -- Linux binary -- GPG signature of the Linux binary -- SHA256 of binary -- Source code -- Wasm binaries of any runtimes - -### Release notes - -The release notes should list: - -- The priority of the release (i.e., how quickly users should upgrade) -- Which native runtimes and their versions are included -- The proposal hashes of the runtimes as built with [srtool](https://gitlab.com/chevdor/srtool) - -The release notes may also list: - -- Free text at the beginning of the notes mentioning anything important regarding this release -- Notable changes (those labelled with B[1-9]-* labels) separated into sections - -### Spec Version - -A runtime upgrade must bump the spec number. This may follow a pattern with the client release -(e.g. runtime v12 corresponds to v0.8.12, even if the current runtime is not v11). - -### New Migrations - -Ensure that any migrations that are required due to storage or logic changes are included in the -`on_runtime_upgrade` function of the appropriate pallets. - -### Old Migrations Removed - -Any previous `on_runtime_upgrade` functions from old upgrades must be removed to prevent them from -executing a second time. - -### Extrinsic Ordering - -Offline signing libraries depend on a consistent ordering of call indices and functions. Compare -the metadata of the current and new runtimes and ensure that the `module index, call index` tuples -map to the same set of functions. In case of a breaking change, increase `transaction_version`. - -Note: Adding new functions to the runtime does not constitute a breaking change as long as they are -added to the end of a pallet (i.e., does not break any other call index). - -### Proxy Filtering - -The runtime contains proxy filters that map proxy types to allowable calls. If the new runtime -contains any new calls, verify that the proxy filters are up to date to include them. - -### Benchmarks - -Run the benchmarking suite with the new runtime and update any function weights if necessary. - -### Polkadot JS - -Ensure that a release of [Polkadot JS API]() contains any new types or interfaces necessary to -interact with the new runtime. +Polkadot Release Process +------------------------ + +### Branches +* release-candidate branch: The branch used for staging of the next release. + Named like `release-v0.8.26` +* release branch: The branch to which successful release-candidates are merged + and tagged with the new version. Named literally `release`. + +### Notes +* The release-candidate branch *must* be made in the paritytech/polkadot repo in +order for release automation to work correctly +* Any new pushes/merges to the release-candidate branch (for example, +refs/heads/release-v0.8.26) will result in the rc index being bumped (e.g., v0.8.26-rc1 +to v0.8.26-rc2) and new wasms built. + +### Release workflow + +Below are the steps of the release workflow. Steps prefixed with NOACTION are +automated and require no human action. + +1. To initiate the release process, branch master off to a release branch and push it to Github: + - `git checkout master; git pull; git checkout -b release-v0.8.26; git push origin refs/heads/release-v0.8.26` +2. NOACTION: The current HEAD of the release-candidate branch is tagged `v0.8.26-rc1` +3. NOACTION: A draft release and runtime WASMs are created for this + release-candidate automatically. A link to the draft release will be linked in + the internal polkadot matrix channel. +4. NOACTION: A new Github issue is created containing a checklist of manual + steps to be completed before we are confident with the release. This will be + linked in Matrix. +5. Complete the steps in the issue created in step 4, signing them off as + completed +6. (optional) If a fix is required to the release-candidate: + 1. Merge the fix with `master` first + 2. Checkout the release-candidate branch and merge `master` + 3. Revert all changes since the creation of the release-candidate that are + **not** required for the fix. + 4. Push the release-candidate branch to Github - this is now the new release- + candidate +7. Once happy with the release-candidate, perform the release using the release + script located at `scripts/release.sh` (or perform the steps in that script + manually): + - `./scripts/release.sh v0.8.26` +8. NOACTION: The HEAD of the `release` branch will be tagged with `v0.8.26`, + and a final release will be created on Github. \ No newline at end of file diff --git a/scripts/github/generate_release_text.rb b/scripts/github/generate_release_text.rb index d113c5b1f1bd..5e91d50cfc04 100644 --- a/scripts/github/generate_release_text.rb +++ b/scripts/github/generate_release_text.rb @@ -1,17 +1,22 @@ # frozen_string_literal: true +require 'base64' require 'changelogerator' -require 'git' require 'erb' -require 'toml' +require 'git' require 'json' +require 'octokit' +require 'toml' +require 'pry' require_relative './lib.rb' -version = ENV['GITHUB_REF'] +current_ref = ENV['GITHUB_REF'] token = ENV['GITHUB_TOKEN'] +github_client = Octokit::Client.new( + access_token: token +) polkadot_path = ENV['GITHUB_WORKSPACE'] + '/polkadot/' -pg = Git.open(polkadot_path) # Generate an ERB renderer based on the template .erb file renderer = ERB.new( @@ -19,29 +24,29 @@ trim_mode: '<>' ) -# get last polkadot version. Use handy Gem::Version for sorting by version -last_version = pg - .tags - .map(&:name) - .grep(/^v\d+\.\d+\.\d+.*$/) - .sort_by { |v| Gem::Version.new(v.slice(1...)) }[-2] +# get ref of last polkadot release +last_ref = "refs/tags/" + github_client.latest_release(ENV['GITHUB_REPOSITORY']).tag_name polkadot_cl = Changelog.new( - 'paritytech/polkadot', last_version, version, token: token + 'paritytech/polkadot', last_ref, current_ref, token: token ) -# Get prev and cur substrate SHAs - parse the old and current Cargo.lock for -# polkadot and extract the sha that way. -prev_cargo = TOML::Parser.new(pg.show("#{last_version}:Cargo.lock")).parsed -current_cargo = TOML::Parser.new(pg.show("#{version}:Cargo.lock")).parsed - -substrate_prev_sha = prev_cargo['package'] - .find { |p| p['name'] == 'sc-cli' }['source'] - .split('#').last - -substrate_cur_sha = current_cargo['package'] - .find { |p| p['name'] == 'sc-cli' }['source'] - .split('#').last +# Gets the substrate commit hash used for a given polkadot ref +def get_substrate_commit(client, ref) + cargo = TOML::Parser.new( + Base64.decode64( + client.contents( + ENV['GITHUB_REPOSITORY'], + path: 'Cargo.lock', + query: { ref: "#{ref}"} + ).content + ) + ).parsed + cargo['package'].find { |p| p['name'] == 'sc-cli' }['source'].split('#').last +end + +substrate_prev_sha = get_substrate_commit(github_client, last_ref) +substrate_cur_sha = get_substrate_commit(github_client, current_ref) substrate_cl = Changelog.new( 'paritytech/substrate', substrate_prev_sha, substrate_cur_sha, @@ -62,7 +67,7 @@ # Pulled from the previous Github step rustc_stable = ENV['RUSTC_STABLE'] rustc_nightly = ENV['RUSTC_NIGHTLY'] - +binding.pry polkadot_runtime = get_runtime('polkadot', polkadot_path) kusama_runtime = get_runtime('kusama', polkadot_path) westend_runtime = get_runtime('westend', polkadot_path) diff --git a/scripts/release.sh b/scripts/release.sh new file mode 100755 index 000000000000..323fee1af01b --- /dev/null +++ b/scripts/release.sh @@ -0,0 +1,28 @@ +#!/usr/bin/env bash +set -e + +# This script is to be run when we are happy with a release candidate. +# It accepts a single argument: version, in the format 'v1.2.3' + +version="$1" +if [ -z "$version" ]; then + echo "No version specified, cannot continue" + exit 1 +fi + +if [[ ! "$version" =~ ^v[0-9]+\.[0-9]+\.[0-9]+$ ]]; then + echo "Version should be in the format v1.2.3" + exit 1 +fi + +echo '[+] Checking out the release branch' +git checkout release +echo '[+] Pulling latest version of the release branch from github' +git pull +echo '[+] Attempting to merge the release-candidate branch to the release branch' +git merge "$version" +echo '[+] Tagging the release' +git tag -s -m "$version" "$version" +echo '[+] Pushing the release branch and tag to Github. A new release will be created shortly' +git push origin release +git push origin "refs/tags/$version"