From d8baeea02a2c3c4d5ba7fb9d1344e74f3f3c53f7 Mon Sep 17 00:00:00 2001 From: Yorke Rhodes Date: Mon, 19 Jul 2021 16:17:53 -0400 Subject: [PATCH] Update release process docs to reflect simpler tagging scheme (#8267) ### Description Fixes contract release process scripts and docs to use simplified tagging scheme ### Tested CI ### Backwards compatibility Yes ### Documentation Smart contract release process docs --- .../release-process/smart-contracts.md | 42 +++++++------------ .../protocol/scripts/bash/check-versions.sh | 3 -- .../bash/generate-old-devchain-and-build.sh | 2 +- packages/protocol/scripts/bash/release-lib.sh | 2 + .../protocol/scripts/bash/verify-release.sh | 2 - 5 files changed, 18 insertions(+), 33 deletions(-) diff --git a/packages/docs/community/release-process/smart-contracts.md b/packages/docs/community/release-process/smart-contracts.md index 40a1829bd10..e524c111613 100644 --- a/packages/docs/community/release-process/smart-contracts.md +++ b/packages/docs/community/release-process/smart-contracts.md @@ -31,25 +31,20 @@ Whenever Celo Core Contracts need to be re-initialized, their initialization arg ### Release management in Git/Github -Github branches/tags and Github releases are used to coordinate past and ongoing releases. Ongoing smart contract development is done on the `master` branch (even after release branches are cut). Every smart contract release has a designated release branch, e.g. `release/celo-core-contracts/${N}` in the celo-monorepo. +Github branches/tags and Github releases are used to coordinate past and ongoing releases. Ongoing smart contract development is done on the `master` branch (even after release branches are cut). Every smart contract release has a designated release branch, e.g. `release/core-contracts/${N}` in the celo-monorepo. #### When a new release branch is cut: -1. A new release branch is created `release/celo-core-contracts/${N}` with the contracts to be audited. -2. The latest commit on the release branch is tagged with `celo-core-contracts-v${N}.pre-audit`. +1. A new release branch is created `release/core-contracts/${N}` with the contracts to be audited. +2. The latest commit on the release branch is tagged with `core-contracts.v${N}.pre-audit`. 3. On Github, a pre-release Github release should be created pointing at the latest tag on the release branch. -4. On master branch, `.circleci/config.yml` should be edited so that the variable `RELEASE_TAG` points to the tag `celo-core-contracts-v${N}.pre-audit` so that all future changes to master are versioned against the new release. -5. Ongoing audit responses/fixes should continue to go into `release/celo-core-contracts/${N}`. - -#### During the release proposal stage: - -1. Whenever release candidates are available they should be tagged `celo-core-contracts-v${N}.rc1`, `...rc2`, etc. -2. When a release is getting proposed on a Baklava/Alfajores/Mainnet, the commit that was used (which should be the latest release candidate) should be tagged with `celo-core-contracts-v${N}.(baklava | alfajores | mainnet)`. +4. On master branch, `.circleci/config.yml` should be edited so that the variable `RELEASE_TAG` points to the tag `core-contracts.v${N}.pre-audit` so that all future changes to master are versioned against the new release. +5. Ongoing audit responses/fixes should continue to go into `release/core-contracts/${N}`. #### After a completed release process: 1. The release branch should be merged into `master` with a merge commit (instead of the usual squash merge strategy). -2. On master branch, `.circleci/config.yml` should be edited so that the variable `RELEASE_TAG` points to the tag `celo-core-contracts-v${N}.mainnet` +2. On master branch, `.circleci/config.yml` should be edited so that the variable `RELEASE_TAG` points to the tag `core-contracts.v${N}` ## Release Process @@ -78,8 +73,8 @@ yarn view-tags ```bash # Run from `packages/protocol` in the celo-monorepo +PREVIOUS_RELEASE="core-contracts.v${N-1}" NETWORK=${"baklava"|"alfajores"|"mainnet"} -PREVIOUS_RELEASE="celo-core-contracts-v${N-1}.${NETWORK}" # A -f boolean flag can be provided to use a forno full node to connect to the provided network yarn verify-deployed -n $NETWORK -b $PREVIOUS_RELEASE -f ``` @@ -112,9 +107,8 @@ check for it. The script generates a detailed report on version changes in JSON format. ```bash -NETWORK=${"baklava"|"alfajores"|"mainnet"} -PREVIOUS_RELEASE="celo-core-contracts-v${N-1}.${NETWORK}" -RELEASE_CANDIDATE="celo-core-contracts-v${N}.rc${X}" +PREVIOUS_RELEASE="core-contracts.v${N-1}" +RELEASE_CANDIDATE="core-contracts.v${N}" yarn check-versions -a $PREVIOUS_RELEASE -b $RELEASE_CANDIDATE -r "report.json" ``` @@ -127,7 +121,7 @@ STORAGE updates are adopted by deploying a new proxy/implementation pair. This s ```bash NETWORK=${"baklava"|"alfajores"|"mainnet"} -RELEASE_CANDIDATE="celo-core-contracts-v${N}.rc${X}" +RELEASE_CANDIDATE="core-contracts.v${N}" yarn make-release -b $RELEASE_CANDIDATE -n $NETWORK -r "report.json" -i "releaseData/initializationData/release${N}.json" -p "proposal.json" -l "libraries.json" ``` @@ -159,7 +153,7 @@ accepted contract upgrade (in the form of the proposal.json you fetched in the s Additionally, include `initialization_data.json` from the CGP if any of the contracts have to be initialized. ```bash -RELEASE_CANDIDATE="celo-core-contracts-v${N}.rc${X}" +RELEASE_CANDIDATE="core-contracts.v${N}" NETWORK=${"baklava"|"alfajores"|"mainnet"} # A -f boolean flag can be provided to use a forno full node to connect to the provided network yarn verify-release -p "upgrade_proposal.json" -b $RELEASE_CANDIDATE -n $NETWORK -f -i initialization_data.json @@ -170,7 +164,7 @@ yarn verify-release -p "upgrade_proposal.json" -b $RELEASE_CANDIDATE -n $NETWORK After a release executes via Governance, you can use `verify-deployed` again to check that the resulting network state does indeed reflect the tagged release candidate: ```bash -RELEASE="celo-core-contracts-v${N}.rc${X}" +RELEASE="core-contracts.v${N}" NETWORK=${"baklava"|"alfajores"|"mainnet"} yarn verify-deployed -n $NETWORK -b $RELEASE -f ``` @@ -288,13 +282,9 @@ Deploying a new contract release should occur with the following process. On-cha T+2w
    -
  1. On Tuesday: Run the smart contract release script in order to to deploy the contracts to Baklava as well as submit a governance proposal. -
      -
    • Transition proposal through Baklava governance process.
      • -
    • Tag the commit that is being proposed with celo-core-contracts-v${N}.baklava
      • -
    -
    2. -
  2. Update your forum post with the Baklava PROPOSAL_ID, updated timings (if any changes), and notify the community in the Discord #governance channel.
    3. +
  3. On Tuesday: Run the smart contract release script in order to to deploy the contracts to Baklava as well as submit a governance proposal. +
  4. Transition proposal through Baklava governance process.
    5. +
  5. Update your forum post with the Baklava PROPOSAL_ID, updated timings (if any changes), and notify the community in the Discord #governance channel.
@@ -304,7 +294,6 @@ Deploying a new contract release should occur with the following process. On-cha
  1. Confirm all contracts working as intended on Baklava.
  2. Run the smart contract release script in order to to deploy the contracts to Alfajores as well as submit a governance proposal.
    3. -
  3. Tag the commit that is being proposed with celo-core-contracts-v${N}.alfajores
  4. Update your forum post with the Alfajores PROPOSAL_ID, updated timings (if any changes), and notify the community in the Discord #governance channel.
@@ -316,7 +305,6 @@ Deploying a new contract release should occur with the following process. On-cha
  • Confirm all contracts working as intended on Alfajores.
  • Confirm audit is complete and make the release notes and forum post contain a link to it.
  • On Tuesday: Run the smart contract release script in order to to deploy the contracts to Mainnet as well as submit a governance proposal.
    • -
  • Tag the commit that is being proposed with celo-core-contracts-v${N}.mainnet
  • Update the corresponding governance proposal with the updated on-chain PROPOSAL_ID and mark CGP status as "PROPOSED".
  • Update your forum post with the Mainnet PROPOSAL_ID, updated timings (if any changes), and notify the community in the Discord #governance channel.
  • At this point all stakeholders are encouraged to verify the proposed contracts deployed match the contracts from the release branch.
    • diff --git a/packages/protocol/scripts/bash/check-versions.sh b/packages/protocol/scripts/bash/check-versions.sh index 4f0f2759884..363a4970163 100755 --- a/packages/protocol/scripts/bash/check-versions.sh +++ b/packages/protocol/scripts/bash/check-versions.sh @@ -37,9 +37,6 @@ if [ ! -z "$REPORT" ]; then REPORT_FLAG="--output_file "$REPORT fi -# fetch tags -git fetch origin +'refs/tags/celo-core-contracts*:refs/tags/celo-core-contracts*' >> $LOG_FILE - source scripts/bash/release-lib.sh build_tag $OLD_BRANCH $LOG_FILE diff --git a/packages/protocol/scripts/bash/generate-old-devchain-and-build.sh b/packages/protocol/scripts/bash/generate-old-devchain-and-build.sh index d663da8e037..c44f02349ee 100755 --- a/packages/protocol/scripts/bash/generate-old-devchain-and-build.sh +++ b/packages/protocol/scripts/bash/generate-old-devchain-and-build.sh @@ -30,7 +30,7 @@ done [ -z "$BUILD_DIR" ] && BUILD_DIR=$(echo build/$(echo $BRANCH | sed -e 's/\//_/g')); echo "- Checkout source code at $BRANCH" -git fetch origin +'refs/tags/celo-core-contracts*:refs/tags/celo-core-contracts*' 2>>$LOG_FILE >> $LOG_FILE +git fetch origin +'refs/tags/core-contracts.*:refs/tags/core-contracts.*' 2>>$LOG_FILE >> $LOG_FILE git checkout $BRANCH 2>>$LOG_FILE >> $LOG_FILE echo "- Build contract artifacts" diff --git a/packages/protocol/scripts/bash/release-lib.sh b/packages/protocol/scripts/bash/release-lib.sh index c27684f8f45..12047cefb5c 100644 --- a/packages/protocol/scripts/bash/release-lib.sh +++ b/packages/protocol/scripts/bash/release-lib.sh @@ -11,6 +11,8 @@ function build_tag() { local BRANCH="$1" local LOG_FILE="$2" + git fetch origin +'refs/tags/core-contracts.v*:refs/tags/core-contracts.v*' >> $LOG_FILE + echo " - Checkout contracts source code at $BRANCH" BUILD_DIR=$(echo build/$(echo $BRANCH | sed -e 's/\//_/g')) [ -d contracts ] && rm -r contracts diff --git a/packages/protocol/scripts/bash/verify-release.sh b/packages/protocol/scripts/bash/verify-release.sh index 121244f4936..138fe777daf 100755 --- a/packages/protocol/scripts/bash/verify-release.sh +++ b/packages/protocol/scripts/bash/verify-release.sh @@ -37,8 +37,6 @@ done [ -z "$NETWORK" ] && echo "Need to set the network via the -n flag" && exit 1; [ -z "$PROPOSAL" ] && echo "Need to set the proposal via the -p flag" && exit 1; -git fetch origin +'refs/tags/celo-core-contracts*:refs/tags/celo-core-contracts*' >> $LOG_FILE - source scripts/bash/release-lib.sh build_tag $BRANCH $LOG_FILE