Skip to main content
This page is for people developing OP Deployer itself. If you only need to pick the right OP Deployer release for your contract version, see the releases reference.

Publish a Release

Pushing an op-deployer/vX.Y.Z tag runs the release-op-deployer GitHub Actions workflow, which builds the binaries and attaches them to a draft GitHub release. If the tagged commit doesn’t contain the workflow, run it from develop with the tag as its input. Wait until the workflow run succeeds, then add the release notes and publish the draft:
Releases are immutable. A release published before its assets are attached can never receive them, so you would need a new tag. Tools such as netchef can only download the binaries once the release is published.

Backport a Fix to an Earlier Version

From time to time, we may backport bugfixes from develop onto earlier versions of OP Deployer. The process for this is as follows:
  1. If one doesn’t exist already, make a new branch for the version lineage you’re patching (e.g. v0.2.x). This branch should be protected (not deletable) and should be based on the latest release of that lineage. The branch should be named as follows: backports/op-deployer/<lineage, i.e. v0.2.0>.
  2. Open a PR with the backport against that branch. Be sure to reference the original commit in the backport.
  3. Make and push a new tag on that lineage.
Example for backporting fix(es) from develop to create a new release op-deployer/v0.2.1:

Add Support for a New Contract Version

Adding support for a new contract version is a multi-step process. Here’s a high-level overview. For the sake of simplicity we will assume you are adding support for a new rc release. OP Deployer is released from the same proposal/op-contracts/vX.Y.Z branch as the contracts it supports, so the two stay compatible while contract development continues on develop. The contract artifacts are embedded in the binary at build time from that checkout, so there is nothing to publish or pin for them.

Step 1: Add Support on Develop

First, you need to add support for the new contract version on the develop branch. This means ensuring that the deployment pipeline supports whatever changes are required for the new version. Typically, this means passing in new deployment variables, and responding to ABI changes in the Solidity scripts/OPCM.

Step 2: Tag the Contracts Release

The contracts team tags the release as op-contracts/vX.Y.Z-rc.n and deploys the OPCM, following the contracts release process. The OP Deployer release is cut from the same commit.

Step 3: Update the SR With the New Release

Add the new RC to the standard versions in the superchain-registry, with the addresses from the OPCM deployment.

Step 4: Update the Validation Package and the Current Tag

The SR is pulled into OP Deployer via the validation package. On the proposal branch, update it:
Then, in op-deployer/pkg/deployer/standard/standard.go, add a constant for the new tag and point CurrentTag at it:
CurrentTag is how OP Deployer resolves the standard OPCM address from the registry. Open a PR against the proposal branch. Once it merges, cherry-pick the OP Deployer changes to develop.

Step 5: Tag the Release

The OP Deployer minor version tracks the contracts major version: contracts vX.0.0 pairs with op-deployer/v0.X.0. Tag the head of the proposal branch and push the tag:
The tag triggers the CircleCI release workflow, which publishes the docker images, and the release-op-deployer GitHub Actions workflow, which attaches the binaries to a draft GitHub release and marks a release candidate as a pre-release. Wait for both to finish, then add the release notes and publish the draft. Announce the release in #proj-op-deployer and #solutions.