refactor(ops): rename add-chain to ops (#725)

* rename add-chain dir to scr-ops

* update justfile

* update doc

* more justfile updates

* update tests

* update module name

* update more docs

* update code comments

* update ci pipeline

* update go.work

* fix justfile typo

* rename to ops

* update tests

* update addnewchain test method name

* Update justfile

---------

Co-authored-by: George Knee <[email protected]>

Author: edobry

.circleci/main_config.yml

@@ -35,7 +35,7 @@ commands:
   install-foundry:
     steps:
       - run:
-          # need foundry to execute 'cast call' within add-chain script
+          # need foundry to execute 'cast call' within ops script
           name: Install foundry
           command: |
             echo "SHELL=$SHELL"
@@ -116,8 +116,8 @@ jobs:
           name: run validation module unit tests
           command: just test-validation
       - run:
-          name: run add-chain module unit tests
-          command: just test-add-chain
+          name: run ops module unit tests
+          command: just test-ops
       - notify-failures-on-main:
           channel: C03N11M0BBN # to slack channel `notify-ci-failures`
           # TODO this should also be filtered on modified chains

CONTRIBUTING.md

@@ -3,27 +3,28 @@
 > [!WARNING]
 > `CONTRIBUTING.md` contains guidelines for modifying or working with the code in the Superchain Registry, including the validation checks and exported modules.
 >
-> For guidelines on how to add a chain to the Registry, see the documentation for [adding a new chain](docs/add-chain.md).
+> For guidelines on how to add a chain to the Registry, see the documentation for [adding a new chain](docs/ops.md#adding-a-chain).
 
 The Superchain Registry repository contains:
-* raw ["per-chain" config data](./README.md#3-understand-output) in `toml` and `json/json.gz` files arranged in a semantically meaningful directory structure
-* [superchain-wide config data](#superchain-wide-config-data)
-* a Go workspace with
+
+- raw ["per-chain" config data](./README.md#3-understand-output) in `toml` and `json/json.gz` files arranged in a semantically meaningful directory structure
+- [superchain-wide config data](#superchain-wide-config-data)
+- a Go workspace with
   - a [`superchain`](#superchain-go-module) module
   - a [`validation`](#validation-go-module) module
-  - an [`add-chain`](#add-chain-go-module) module
+  - an [`ops`](#ops-go-module) module
   - The modules are tracked by a top level `go.work` file. The associated `go.work.sum` file is gitignored and not important to typical workflows, which should mirror those of the [CI configuration](.circleci/config.yml).
-* Automatically generated summary `chainList.json` and `chainList.toml` files.
-
+- Automatically generated summary `chainList.json` and `chainList.toml` files.
 
 ## Superchain-wide config data
-A superchain target defines a set of layer 2 chains which share a `SuperchainConfig` and `ProtocolVersions` contract deployment on layer 1. It is usually named after the layer 1 chain, possibly with an extra identifier to distinguish devnets.
 
+A superchain target defines a set of layer 2 chains which share a `SuperchainConfig` and `ProtocolVersions` contract deployment on layer 1. It is usually named after the layer 1 chain, possibly with an extra identifier to distinguish devnets.
 
 > **Note**
 > Example: `sepolia` and `sepolia-dev-0` are distinct superchain targets, although they are on the same layer 1 chain.
 
 ### Adding a superchain target
+
 A new Superchain Target can be added by creating a new superchain config directory,
 with a `superchain.yaml` config file.
 
@@ -49,25 +50,25 @@ protocol_versions_addr: null # todo
 superchain_config_addr: null # todo
 EOF
 ```
-Superchain-wide configuration, like the `ProtocolVersions` contract address, should be configured here when available.
-
-
 
+Superchain-wide configuration, like the `ProtocolVersions` contract address, should be configured here when available.
 
 ## `superchain` Go Module
 
 Per chain and superchain-wide configs and extra data are embedded into the `superchain` go module, which can be imported like so:
 
-```
+```shell
 go get github.com/ethereum-optimism/superchain-registry/superchain@latest
 ```
-The configs are consumed by downstream OP Stack software, i.e. `op-geth` and `op-node`.
 
+The configs are consumed by downstream OP Stack software, i.e. `op-geth` and `op-node`.
 
 ## `validation` Go Module
+
 A second module exists in this repo whose purpose is to validate the config exported by the `superchain` module. It is a separate module to avoid import cycles and polluting downstream dependencies with things like `go-ethereum` (which is used in the validation tests).
 
-## `add-chain` Go module
+## `ops` Go module
+
 This module contains the CLI tool for generating `superchain` compliant configs and extra data to the registry.
 
 ## CheckSecurityConfigs
@@ -158,6 +159,7 @@ graph TD
 ```
 
 ## Setting up your editor for formatting and linting
+
 If you use VSCode, you can place the following in a `settings.json` file in the gitignored `.vscode` directory:
 
 ```json
@@ -171,8 +173,8 @@ If you use VSCode, you can place the following in a `settings.json` file in the
 }
 ```
 
-
 ## Links
+
 See [Superchain Upgrades] OP Stack specifications.
 
 [Superchain Upgrades]: https://specs.optimism.io/protocol/superchain-upgrades.html

README.md

@@ -7,9 +7,9 @@ The Superchain Registry is an index of chains which serves as the source of trut
 
 ## Quickstart
 
-* ### [👀 See who's in the Superchain Ecosystem](chainList.json)
-* ### [⚙️ View detailed config information for each chain](superchain/configs)
-* ### [📝 Add a new chain to the Superchain Registry](docs/add-chain.md)
+- ### [👀 See who's in the Superchain Ecosystem](chainList.json)
+- ### [⚙️ View detailed config information for each chain](superchain/configs)
+- ### [📝 Add a new chain to the Superchain Registry](docs/ops.md#adding-a-chain)
 
 ## More about the Superchain Registry
 

docs/add-chain.md renamed to docs/ops.md

@@ -1,4 +1,6 @@
-# Adding a Chain
+# Superchain Registry Operations (ops)
+
+## Adding a Chain
 
 The following are the steps you need to take to add a chain to the registry:
 
@@ -9,6 +11,7 @@ The following are the steps you need to take to add a chain to the registry:
 > added to the registry.
 
 ### 0. Fork this repository
+
 You will be raising a Pull Request from your fork to the upstream repo.
 
 We recommend only adding one chain at a time, and starting with a fresh branch of this repo for every chain.
@@ -46,7 +49,9 @@ just add-chain
 The remaining steps should then be followed to merge the config data into the registry -- a prerequisite for [promoting the chain](#promote-a-chain-to-standard) to a standard chain.
 
 ### 4. Understand output
+
 The tool will write the following data:
+
 - The main configuration source, with genesis data, and address of onchain system configuration. These are written to `superchain/configs/<superchain-target>/<chain-short-name>.toml`.
 - Hardfork override times, where they have been set, will be included. If and when a chain becomes a standard chain, a `superchain_time` is set in the chain config. From that time on, future hardfork activation times which are missing from the chain config will be inherited from superchain-wide values in the neighboring `superchain.toml` file.
 - Genesis system config data
@@ -56,13 +61,15 @@ The genesis largely consists of contracts common with other chains:
 all contract bytecode is deduplicated and hosted in the `extra/bytecodes` directory.
 
 The format is a gzipped JSON `genesis.json` file, with either:
+
 - a `alloc` attribute, structured like a standard `genesis.json`, but with `codeHash` (bytes32, `keccak256` hash of contract code) attribute per account, instead of the `code` attribute seen in standard Ethereum genesis definitions.
 - a `stateHash` attribute: to omit a large state (e.g. for networks with a re-genesis or migration history). Nodes can load the genesis block header, and state-sync to complete the node initialization.
 
 ### 5. Run tests locally
 
 Run the following commands to run the Go validation checks, for only the chain you added (replace the `<chain-id>` accordingly):
-```
+
+```shell
 just validate <chain-id>
 just validate-genesis-allocs <chain-id>
 ```
@@ -78,7 +85,7 @@ The [`validation_test.go`](./validation/validation_test.go) test declaration fil
 
 This tool will add your chain to the `chainList.toml` and `addresses.json` files, which contain summaries of all chains in the registry.
 
-```
+```shell
 just codegen
 ```
 
@@ -88,23 +95,27 @@ just codegen
 > If anything looks incorrect, please get in touch.
 
 ### 7. Open Your Pull Request
+
 When opening a PR:
+
 - Open it from a non-protected branch in your fork (e.g. avoid the `main` branch). This allows maintainers to push to your branch if needed, which streamlines the review and merge process.
 - Open one PR per chain you would like to add. This ensures the merge of one chain is not blocked by unexpected issues.
 - Once the PR is opened, please check the box to [allow edits from maintainers](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/allowing-changes-to-a-pull-request-branch-created-from-a-fork).
 
 Once the PR is opened, the same automated checks you've run locally will then run on your PR, and your PR will be reviewed in due course. Once these checks pass, the PR will be merged.
 
-
 ## Promote a chain to standard
+
 This process is only possible for chains already in the registry.
 
 Run this command (replace the `<chain-id>` accordingly):
-```
+
+```shell
 just promote-to-standard <chain-id>
 ```
 
 This command will:
-* declare the chain as a standard chain
-* set the `superchain_time`, so that the chain receives future hardforks with the rest of the superchain (baked into downstream OPStack software, selected with [network flags](https://docs.optimism.io/builders/node-operators/configuration/base-config#initialization-via-network-flags)).
-* activate the full suite of validation checks for standard chains, including checks on the `ProxyAdminOwner`
+
+- declare the chain as a standard chain
+- set the `superchain_time`, so that the chain receives future hardforks with the rest of the superchain (baked into downstream OPStack software, selected with [network flags](https://docs.optimism.io/builders/node-operators/configuration/base-config#initialization-via-network-flags)).
+- activate the full suite of validation checks for standard chains, including checks on the `ProxyAdminOwner`

go.work

@@ -1,7 +1,7 @@
 go 1.22.0
 
 use (
-	./add-chain
+	./ops
 	./superchain
 	./validation
 )

justfile

@@ -4,41 +4,41 @@ alias l := lint-all
 
 # Adding a chain
 add-chain:
-	go run ./add-chain add-new-chain
-	go run ./add-chain check-rollup-config
-	go run ./add-chain compress-genesis
-	go run ./add-chain check-genesis
+	go run ./ops add-new-chain
+	go run ./ops check-rollup-config
+	go run ./ops compress-genesis
+	go run ./ops check-genesis
 	just codegen
 
 # Promote a standard candidate chain to a standard chain, example: just promote-to-standard 10
 promote-to-standard CHAIN:
-	go run ./add-chain promote-to-standard --chain-id={{CHAIN}}
+	go run ./ops promote-to-standard --chain-id={{CHAIN}}
 	just codegen
 
 # Generate auto-generated files
-codegen: clean-add-chain
+codegen: clean-ops
 	CODEGEN=true go run superchain/internal/codegen/main.go
 
 # Lint all Go code
 lint-all:
-	golangci-lint run superchain/... validation/... add-chain/... --fix
+	golangci-lint run superchain/... validation/... ops/... --fix
 
 # Test all Go code
-test-all: test-add-chain test-superchain test-validation
+test-all: test-ops test-superchain test-validation
 
-# Test all Go code in the add-chain module
-test-add-chain:
+# Test all Go code in the ops module
+test-ops:
 	# We separate the first test from the rest because it generates artifacts
 	# Which need to exist before the remaining tests run.
-	TEST_DIRECTORY=./add-chain go run gotest.tools/gotestsum@latest --format testname -- -count=1 -run TestAddChain_Main
-	TEST_DIRECTORY=./add-chain/... go run gotest.tools/gotestsum@latest --format testname -- -count=1 -run '[^TestAddChain_Main]'
+	TEST_DIRECTORY=./ops go run gotest.tools/gotestsum@latest --format testname -- -count=1 -run TestOps_AddNewChain
+	TEST_DIRECTORY=./ops/... go run gotest.tools/gotestsum@latest --format testname -- -count=1 -run '[^TestOps_AddNewChain]'
 
 # Test all Go code in the superchain module
-test-superchain: clean-add-chain
+test-superchain: clean-ops
 	TEST_DIRECTORY=./superchain go run gotest.tools/gotestsum@latest --format testname
 
 # Unit test all Go code in the validation module, and do not run validation checks themselves
-test-validation: clean-add-chain
+test-validation: clean-ops
 	TEST_DIRECTORY=./validation/... go run gotest.tools/gotestsum@latest --format testname -- -run '[^TestValidation|^TestPromotion|^TestGenesisAllocs]'
 
 # Runs validation checks for any chain whose config changed
@@ -65,18 +65,18 @@ promotion-test:
 validate-standard-candidate CHAIN_ID:
 	TEST_DIRECTORY=./validation go run gotest.tools/gotestsum@latest --format testname -- -run='Promotion/.+\({{CHAIN_ID}}\)$' -count=1
 
-# Clean test files generated by the add-chain tooling
-clean-add-chain:
+# Clean test files generated by the ops tooling
+clean-ops:
 	rm -f superchain/configs/sepolia/testchain_*.toml
 	rm -f superchain/extra/sepolia/testchain_*.json.gz
 	rm -rf -- validation/genesis/validation-inputs/*-test/
 
 # Tidying all go.mod files
-tidy-all: tidy-add-chain tidy-superchain tidy-validation
+tidy-all: tidy-ops tidy-superchain tidy-validation
 
-# Tidy the add-chain go.mod file
-tidy-add-chain:
-	cd add-chain && go mod tidy
+# Tidy the ops go.mod file
+tidy-ops:
+	cd ops && go mod tidy
 
 # Tidy the superchain go.mod file
 tidy-superchain:

add-chain/.gitignore renamed to ops/.gitignore

@@ -13,9 +13,9 @@ import (
 	"github.com/BurntSushi/toml"
 	"github.com/ethereum-optimism/optimism/op-e2e/bindings"
 	"github.com/ethereum-optimism/optimism/op-service/retry"
-	"github.com/ethereum-optimism/superchain-registry/add-chain/config"
-	"github.com/ethereum-optimism/superchain-registry/add-chain/flags"
-	"github.com/ethereum-optimism/superchain-registry/add-chain/utils"
+	"github.com/ethereum-optimism/superchain-registry/ops/config"
+	"github.com/ethereum-optimism/superchain-registry/ops/flags"
+	"github.com/ethereum-optimism/superchain-registry/ops/utils"
 	"github.com/ethereum-optimism/superchain-registry/superchain"
 	"github.com/ethereum-optimism/superchain-registry/validation"
 	"github.com/ethereum-optimism/superchain-registry/validation/genesis"
@@ -271,7 +271,7 @@ func writeGenesisValidationMetadata(commit string, targetDir string) error {
 	// Define default metadata params:
 	// These may not be sufficient to make the genesis validation work,
 	// but we address that with some manual trial-and-error intervention
-	// involving OPLabs engineers after the add-chain command runs.
+	// involving OPLabs engineers after the add-new-chain command runs.
 	const defaultNodeVersion = "18.12.1"
 	const defaultMonorepoBuildCommand = "pnpm"
 	const defaultGenesisCreationCommand = "forge1" // See validation/genesis/commands.go

add-chain/cmd/add-new-chain.go renamed to ops/cmd/add-new-chain.go

@@ -6,7 +6,7 @@ import (
 	"math/big"
 	"os"
 
-	"github.com/ethereum-optimism/superchain-registry/add-chain/flags"
+	"github.com/ethereum-optimism/superchain-registry/ops/flags"
 	"github.com/ethereum/go-ethereum/core"
 	"github.com/google/go-cmp/cmp"
 	"github.com/google/go-cmp/cmp/cmpopts"

add-chain/cmd/check-genesis.go renamed to ops/cmd/check-genesis.go

@@ -7,7 +7,7 @@ import (
 	"os"
 
 	"github.com/ethereum-optimism/optimism/op-node/rollup"
-	"github.com/ethereum-optimism/superchain-registry/add-chain/flags"
+	"github.com/ethereum-optimism/superchain-registry/ops/flags"
 	"github.com/ethereum/go-ethereum/common"
 	"github.com/google/go-cmp/cmp"
 	"github.com/google/go-cmp/cmp/cmpopts"