Teleporter release flow

[geoff-vball]

Why this should be merged

Closes #199

Adds a release flow to the CI which will create a new release and attach the relevant artifacts when a new version tag is pushed.

Adds deploy_teleporter.sh script to deploy any teleporter release to any chain.

How this works

The CI release flow is triggered on any pushed tag matching v*.*.0 (major and minor version bumps). #199 Discusses only triggering on major bumps, but with how golang treats major version bumps I think we may want to stick to minor version bumps for new versions of the TeleporterMessenger contract.

The release will contain a changelog of all the PRs merged since the last release, and will contain .txt files for the deployer address, contract address, and deployer transaction.

deploy_teleporter.sh requires a teleporter release version and an rpc url. It optionally takes a private key if they user wants to fund the deployer address directly from the script.

How this was tested

Local network using a slightly modified run.sh that does not deploy the teleporter contract for one subnet.

How is this documented

--help option in deploy_teleporter.sh

[michaelkaplan13]

LGTM. I don't know of a good way to test the release workflow without creating a release. Once merged, I recommend testing with a v0.0.0 release that can be later removed once tested.

[cam-schultz]

Why do we require the bugfix version to be 0 in order to issue a release? It's possible we'd release a fix that did not change the interface at all, in which case we'd want to tag it as a bugfix.

I don't think we should use semver tags for non-contract changes. Those can either be rc's or left untagged.

[geoff-vball]

We can still manually make releases for the whole repo for, let's say v.0.1.2, but it won't trigger this flow. This flow just adds in the teleporter contract artifacts, which we only want to do for a new version of the teleporter contract.

To treat semver properly, we would probably only generate the teleporter artifacts on major version changes, but with the way golang treats major version changes, I think we should stick with minor versions.

[cam-schultz]

we would probably only generate the teleporter artifacts on major version changes

I think it's possible we'd generate Teleporter artifacts for major, minor, or bug fix versions. We should treat this as a Solidity repository primarily, and have the tagged releases map to Teleporter and the supporting contracts. Other changes, including the Golang tests and the example contracts, should not constitute tagged releases on their own IMO.

[michaelkaplan13]

With how Nick's method is used to deploy the contract to the same address on every chain, any change to the contract (even one that doesn't change the interface) would be a "breaking" change in the sense that the new contract will be deployed to a new address and not be able to send/receive message from older versions.

I think it makes sense to leave bugfix versions for changes to the test and/or golang utilities that other repos may consume, and require that any change to the Teleporter contract itself be at least a new minor version. While the "teleporter version" numbers in the registry contracts are completely independent, I think we should only create new Teleporter contract releases when we plan on updating the commonly used registries via an off-chain warp message.

[cam-schultz]

Sounds good to me. Can we document somewhere how we're planning on treating release versions since we're diverging from semver as a it relates to the Teleporter contract? @geoff-vball

[geoff-vball]

@cam-schultz Yep I'll add it.

[michaelkaplan13]

Can you add a section to the top level README documenting the usage of deploy_teleporter.sh? I think we should also include explanations regarding the major/minor/bugfix version usage for the repo, and make it clear that each version can only send messages to/from the same version on other chains.

[geoff-vball]

@michaelkaplan13 We currently have a doc at utils/contract-deployment/README.md, linked from the toplevel README that describes how to do all the steps manually. Do you think I should replace that doc entirely? Or leave it and just add details about the deployment script?

[michaelkaplan13]

@michaelkaplan13 We currently have a doc at utils/contract-deployment/README.md, linked from the toplevel README that describes how to do all the steps manually. Do you think I should replace that doc entirely? Or leave it and just add details about the deployment script?

I'd be in favor of adding a new "Deploying TeleporterMessenger to a Subnet" section to the top level README, including how the need for the contract to be deployed to the same address on each chain and the intended usage of the new script.

[michaelkaplan13]

One super small nit on wording, but LGTM!

I think it makes sense to keep the fixed-width text formatting for variable names or commands, so didn't think it made sense for deployer address.

[michaelkaplan13]

🚀 🚢