zeekayandHanzo Dev
9e4aa8c436
luxd serves chain routes under /v1/chain, and the node, cli and sdk releases already ship it. The deployed gateways still answer the old prefix, so remote reads break until they are redeployed; the estate moves together rather than sitting half converted. Lines that record an observation - a probe, a status code, a past release - keep the prefix they were written against, as do URLs on hosts that are not ours. Avalanche endpoints move to /ext/bc, which is the path that host serves. Co-authored-by: Hanzo Dev <[email protected]>
Developing with tmpnet
The load/ and warp/ paths contain end-to-end (e2e) tests that use
the tmpnet
fixture. By
default both test suites use the tmpnet fixture to create a temporary
network that exists for only the duration of their execution.
It is possible to create a temporary network that can be reused across test runs to minimize the setup cost involved:
# From the root of a clone of luxd, build the tmpnetctl cli
$ ./scripts/build_tmpnetctl.sh
# Start a new temporary network configured with evm's default plugin path
$ ./build/tmpnetctl start-network --lux-path=./build/luxd
# From the root of a clone of evm, execute the warp test suite against the existing network
$ ginkgo -vv ./tests/warp -- --use-existing-network --network-dir=$HOME/.tmpnet/networks/latest
# To stop the temporary network when no longer needed, execute the following from the root of the clone of luxd
$ ./build/tmpnetctl stop-network --network-dir=$HOME/.tmpnet/networks/latest
The network started by tmpnetctl won't come with subnets configured,
so the test suite will add them to the network the first time it
runs. Subsequent test runs will be able to reuse those subnets without
having to set them up.
Collection of logs and metrics
Logs and metrics can be optionally collected for tmpnet networks and viewed in grafana. The details of configuration and usage for evm mirror those of luxd and the same documentation applies.
Optional Dev Shell
Some activities, such as collecting metrics and logs from the nodes targeted by an e2e test run, require binary dependencies. One way of making these dependencies available is to use a nix shell which will give access to the dependencies expected by the test tooling:
- Install nix. The determinate systems installer is recommended.
- Use ./scripts/dev_shell.sh to start a nix shell
- Execute the dependency-requiring command (e.g.
ginkgo -v ./tests/warp -- --start-collectors)
This repo also defines a .envrc file to configure devenv. With devenv
and nix installed, a shell at the root of the repo will automatically start a nix dev
shell.