wormchain: run Ignite through docker and update documentation (#2169)

.github/workflows/build.yml

@@ -238,10 +238,11 @@ jobs:
       - uses: actions/setup-go@v2
         with:
           go-version: "1.19.3"
-      - run: wget https://github.com/ignite/cli/releases/download/v0.23.0/ignite_0.23.0_linux_amd64.tar.gz
-      - run: tar xzf ignite_0.23.0_linux_amd64.tar.gz
-      - run : mv ./ignite /usr/local/bin/
-      - run: cd wormchain && make proto -B && make test
+      - run: |
+          cd wormchain
+          make proto -B
+          git diff --name-only --exit-code && echo "✅ Generated proto matches committed proto" || (echo "❌ Generated proto differs from committed proto, run \`make proto -B\` and commit the result" >&2 && exit 1)
+          make test
 
   # Verify go sdk unit tests
   sdk_vaa:

scripts/check-docker-pin.sh

@@ -10,8 +10,9 @@
 #   - We ignore sha256 because it suggests that the image dep is pinned
 #   - We ignore scratch because it's literally the docker base image
 #   - We ignore solana AS (builder|ci_tests) because it's a relative reference to another FROM call
+#   - We ignore base AS (ignite-go-build|ignite-vue-build) because the base image is already pinned in wormchain/Dockerfile.proto
 #
-git ls-files | grep "Dockerfile*" | xargs grep -s "FROM" | egrep -v 'sha256|scratch|solana|aptos|base AS (application|base|builder|ci_tests|tests)'
+git ls-files | grep "Dockerfile*" | xargs grep -s "FROM" | egrep -v 'sha256|scratch|solana|aptos|base AS (application|base|builder|ci_tests|tests|ignite-go-build|ignite-vue-build)'
 if [ $? -eq 0 ]; then
    echo "[!] Unpinned docker files" >&2
    exit 1

wormchain/Dockerfile.proto

@@ -0,0 +1,18 @@
+FROM ignitehq/cli@sha256:1e2846f3621bc3ed2af3e59749bc02f6aec761e1260486da3a17c8fe2c8d2b6c AS base
+
+COPY --chown=tendermint:tendermint wormchain /apps/wormchain
+COPY --chown=tendermint:tendermint sdk /apps/sdk
+
+WORKDIR /apps/wormchain
+
+FROM base AS ignite-go-build
+RUN ignite generate proto-go
+
+FROM scratch AS go-export
+COPY --from=ignite-go-build /apps/wormchain/x/wormhole/types /x/wormhole/types
+
+FROM base AS ignite-vue-build
+RUN NODE_OPTIONS="" ignite generate vuex --proto-all-modules
+
+FROM scratch AS vue-export
+COPY --from=ignite-vue-build /apps/wormchain/vue/ /vue

wormchain/Makefile

@@ -1,6 +1,5 @@
 PROTO_FILES=$(shell find proto -name "*.proto")
 GO_FILES=$(shell find . -name "*.go")
-IGNITE_EXPECTED_VERSION:=v0.23.0
 # Address of the main tilt validator that the others should connect to
 TILT_VALADDRESS=wormholevaloper1cyyzpxplxdzkeea7kwsydadg87357qna87hzv8
 
@@ -16,7 +15,7 @@ ldflags = \
 BUILD_FLAGS := -ldflags '$(ldflags)'
 
 .PHONY: all
-all: client vue validators
+all: client validators
 
 .PHONY: client
 client: build/wormchaind
@@ -44,17 +43,13 @@ validators:
 build/wormchaind: cmd/wormchaind/main.go $(GO_FILES)
 	go build -v $(BUILD_FLAGS) -tags ledger -o $@ $<
 
-check-ignite:
-	@ if [ "$(shell ignite version | awk '/Ignite CLI version:/ { print $$4 }')" != "$(IGNITE_EXPECTED_VERSION)" ] ; then echo "Expected ignite version $(IGNITE_EXPECTED_VERSION)" && exit 1 ; fi
-
-proto: check-ignite $(PROTO_FILES)
-	ignite generate proto-go
-	touch proto
+proto: $(PROTO_FILES)
+	docker build --target go-export -f Dockerfile.proto -o type=local,dest=. ..
 
 vue: $(GO_FILES) proto
 	mkdir -p $@
 	touch -m $@
-	NODE_OPTIONS="" ignite generate vuex --proto-all-modules
+	docker build --target vue-export -f Dockerfile.proto -o type=local,dest=. ..
 
 # For now this is a phony target so we just rebuild it each time instead of
 # tracking dependencies

wormchain/README.md

@@ -1,6 +1,6 @@
 # Wormchain
 
-**Wormchain** is a blockchain built using Cosmos SDK and Tendermint and created with [Starport](https://github.com/tendermint/starport).
+**Wormchain** is a blockchain built using Cosmos SDK and Tendermint and initially created with [Ignite](https://github.com/ignite).
 
 ## Building
 
@@ -16,7 +16,7 @@ See [development.md](./development.md)
 
 ## How to run the tests
 
-    run either "starport chain serve" or "tilt up"
+    run "tilt up -- --wormchain"
     cd ./ts-sdk
     npm ci
     npm run build
@@ -24,10 +24,10 @@ See [development.md](./development.md)
     npm ci
     npm run test
 
-## Learn more about Cosmos & Starport
+## Learn more about Cosmos & Ignite
 
-- [Starport](https://github.com/tendermint/starport)
-- [Starport Docs](https://docs.starport.network)
+- [Ignite](https://github.com/ignite)
+- [Ignite Docs](https://docs.ignite.com/)
 - [Cosmos SDK documentation](https://docs.cosmos.network)
 - [Cosmos SDK Tutorials](https://tutorials.cosmos.network)
 - [Discord](https://discord.gg/cosmosnetwork)

wormchain/development.md

@@ -3,7 +3,6 @@
 ## prerequsites
 
 - Go >= 1.16
-- Starport: `curl https://get.starport.network/starport@v0.19.5! | sudo bash
 - nodejs >= 16
 
 ## Building the blockchain
@@ -44,7 +43,7 @@ Golang tests
 
     make test
 
-Client tests, run against the chain. Wormchain must be running via `starport chain serve`, `make run` or `tilt up`
+Client tests, run against the chain. Wormchain must be running via `make run` or `tilt up -- --wormchain`
 
     cd ./ts-sdk
     npm ci
@@ -65,24 +64,26 @@ Note the flags `--from tiltGuardian --home build`. These have to be passed
 in each time you make a transaction (the `tiltGuardian` account is created in
 `config.yml`). Queries don't need the `--from` flag.
 
-## Scaffolding stuff with starport
+## Scaffolding stuff with Ignite
 
-TODO: expand explanation here
+Wormchain was initially scaffolded using the [Ignite CLI](https://github.com/ignite) (formerly Starport). Now, we only use Ignite for generating code from protobuf definitions.
+
+To avoid system compatibility issues, we run Ignite using docker. The below commands should be run using the ignite docker container (see the Makefile recipes for examples).
 
 ```shell
-starport scaffold type guardian-key key:string --module wormhole --no-message
+ignite scaffold type guardian-key key:string --module wormhole --no-message
 ```
 
 modify `proto/wormhole/guardian_key.proto` (string -> bytes)
 
 ```shell
-starport scaffold message register-account-as-guardian guardian-pubkey:GuardianKey address-bech32:string signature:string --desc "Register a guardian public key with a wormhole chain address." --module wormhole --signer signer
+ignite scaffold message register-account-as-guardian guardian-pubkey:GuardianKey address-bech32:string signature:string --desc "Register a guardian public key with a wormhole chain address." --module wormhole --signer signer
 ```
 
 Scaffold a query:
 
 ```shell
-starport scaffold query latest_guardian_set_index --response LatestGuardianSetIndex --module wormhole
+ignite scaffold query latest_guardian_set_index --response LatestGuardianSetIndex --module wormhole
 ```
 
 (then modify "wormchain/x/wormhole/types/query.pb.go" to change the response type)

wormchain/validators/readme.md

@@ -4,13 +4,13 @@ The intent of this validators directory is to make a network of realish validato
 
 ## How the Tilt environment works:
 
-The Dockerfile in the root directory builds into the directory `/guardian_validator`. The starport build is perfectly useable in a single validator environment, but has the downside of using different tendermint keys each time as part of the starport process. This makes it tricky to write repeatable tests which deal with validator registration or bonding.
+The Dockerfile in the root directory builds into the directory `/guardian_validator`. The ignite build is perfectly useable in a single validator environment, but has the downside of using different tendermint keys each time as part of the ignite process. This makes it tricky to write repeatable tests which deal with validator registration or bonding.
 
-In order for our tests to run determininistically, we want to use the exact same node address, tendermint keys, operator addresses, and guardian keys every single time the tilt environment stands up. However, we also want to capture code changes to the `config.yml`, starport modules, and `cosmos-sdk` fork, so we cannot easily abandon using starport to build and initialize the chain.
+In order for our tests to run determininistically, we want to use the exact same node address, tendermint keys, operator addresses, and guardian keys every single time the tilt environment stands up. However, we also want to capture code changes to the `config.yml`, ignite modules, and `cosmos-sdk` fork, so we cannot easily abandon using ignite to build and initialize the chain.
 
 To accomplish this, we first start a single validator with a fixed Tendermint address, which is specified in the `genesis.json` as both a validator and a Guardian Validator. This first validator can bootstrap the network, and allow all subsequent validators to come online and register.
 
-Thus, `first_validator` (represented in tilt as `guardian-validator`) is a special node. Starport outputs a newly generated validator public key as the only validator in its `genesis.json`. However, the Dockerfile then explicitly runs a `collect-gentxs` command afterwards, which moves the JSON at `/first_validator/genesis/gentx.json` into the genesis file at `/guardian_validator/genesis.json`. The genesis file in the `/guardian_validator` directory is used by all the validators. Thus, after the genesis block, the `first_validator` is the only validator. All later validators come on initially with 0 voting power. The `genesis.json` (specifically, the gentxs it got from `first_validator/genesis/gentxs`) maps the `first_validator`'s tendermint key to the tiltGuardian operator address, and then the `config.yml` file maps the tiltGuardian operator address to the Tilt Guardian Public key by putting it into the genesis init of the Wormhole module.
+Thus, `first_validator` (represented in tilt as `guardian-validator`) is a special node. Ignite outputs a newly generated validator public key as the only validator in its `genesis.json`. However, the Dockerfile then explicitly runs a `collect-gentxs` command afterwards, which moves the JSON at `/first_validator/genesis/gentx.json` into the genesis file at `/guardian_validator/genesis.json`. The genesis file in the `/guardian_validator` directory is used by all the validators. Thus, after the genesis block, the `first_validator` is the only validator. All later validators come on initially with 0 voting power. The `genesis.json` (specifically, the gentxs it got from `first_validator/genesis/gentxs`) maps the `first_validator`'s tendermint key to the tiltGuardian operator address, and then the `config.yml` file maps the tiltGuardian operator address to the Tilt Guardian Public key by putting it into the genesis init of the Wormhole module.
 
 ## How to add new Validators to Tilt