Merge branch 'main' into update-cmd

.github/ISSUE_TEMPLATE/feature_spec.md

@@ -1,18 +1,20 @@
 ---
-name: Feature specification
+name: Feature 
 about: Discussion on design and implementation of new features for the Avalanche CLI.
 title: ''
-labels: enhancement
 assignees: ''
-
 ---
 
-**Context and scope**
-Include a short description of the context and scope of the suggested feature.
-Include goals the change will accomplish if relevant.
+## Goal
+
+### Assumptions and Scope
+
+## Example Usage
+
+### Requirements:
+
+### Current Limitations
 
-**Discussion and alternatives**
-Include a description of the changes to be made to the code along with alternatives that were considered.
+### Nice to Have, but Not Required 
 
-**Open questions**
-Questions that are still being discussed.
+## Open Questions

.github/packer/aws-ubuntu-docker.pkr.hcl

@@ -130,8 +130,8 @@ build {
             "docker pull prom/node-exporter:v1.7.0",
             "docker pull grafana/grafana:10.4.1",
             "docker pull prom/prometheus:v2.51.2",
-            "docker pull avaplatform/awm-relayer",
-            "docker pull golang:1.22.1-bullseye"
+            "docker pull avaplatform/icm-relayer:v2.0.0-fuji",
+            "docker pull golang:1.22.8-bullseye"
         ]
    }
 

.github/workflows/e2e-test.yml

@@ -21,9 +21,13 @@ jobs:
             "\\[Network\\]",
             "\\[Package Management\\]",
             "\\[Root\\]",
-            "\\[Local Subnet\\]",
+            "\\[Local Subnet non SOV\\]",
             "\\[Subnet Compatibility\\]",
-            "\\[Public Subnet\\]",
+            "\\[Public Subnet non SOV\\]",
+            "\\[Etna Subnet SOV\\]",
+            "\\[Etna AddRemove Validator SOV PoA\\]",
+            "\\[Etna AddRemove Validator SOV PoS\\]",
+            "\\[Etna Add Validator SOV Local\\]",
             "\\[Subnet\\]",
             "\\[Upgrade expect network failure\\]",
             "\\[Upgrade public network\\]",
@@ -34,14 +38,22 @@ jobs:
           ]
         os: [ubuntu-latest, macos-14]
         exclude:
+          - os: ubuntu-latest
+            suite: "\\[Etna Subnet SOV\\]"
           - os: macos-14
             suite: "\\[Node create\\]"
           - os: macos-14
             suite: "\\[Node devnet\\]"
           - os: macos-14
             suite: "\\[Docker\\]"
           - os: macos-14
-            suite: "\\[Public Subnet\\]"
+            suite: "\\[Public Subnet non SOV\\]"
+          - os: ubuntu-latest
+            suite: "\\[Etna AddRemove Validator SOV PoA\\]"
+          - os: ubuntu-latest
+            suite: "\\[Etna AddRemove Validator SOV PoS\\]"
+          - os: ubuntu-latest
+            suite: "\\[Etna Add Validator SOV Local\\]"
     steps:
       - name: Checkout repository
         uses: actions/checkout@v4
@@ -76,7 +88,7 @@ jobs:
           npm install -g tsx
 
       - name: Install Docker on MacOS
-        if: ${{ (matrix.os == 'macos-14') && (matrix.suite == '\\[Public Subnet\\]') }}
+        if: ${{ (matrix.os == 'macos-14') && (matrix.suite == '\\[Public Subnet non SOV\\]') }}
         run: |
           brew install docker
           brew install colima

.github/workflows/lint.yml

@@ -21,11 +21,7 @@ jobs:
           go-version-file: 'go.mod'
 
       - name: Lint Golang
-        uses: golangci/golangci-lint-action@v6
-        with:
-          version: v1.56.2
-          working-directory: .
-          args: --timeout 5m
+        run: ./scripts/lint.sh
 
       - name: Check License
         run:  |

.github/workflows/unit-test.yml

@@ -29,7 +29,6 @@ jobs:
       - name: Build and Test
         run: |
           scripts/build.sh
-          go test -v -coverprofile=coverage.out $(go list ./... | grep -v /tests/ | grep -v '/sdk/')
-          go tool cover -func=coverage.out
+          scripts/unit_test.sh
         env:
           CGO_CFLAGS: "-O -D__BLST_PORTABLE__" # Set the CGO flags to use the portable version of BLST

.gitignore

@@ -17,6 +17,7 @@
 
 # Output of the go coverage tool, specifically when used with LiteIDE
 *.out
+*.lcov
 
 # ignore GoLand metafiles directory
 .idea/
@@ -53,3 +54,4 @@ pkg/contract/contracts/cache/
 pkg/contract/contracts/out/
 
 osxcross/
+

README.md

@@ -1,6 +1,6 @@
 # Avalanche-CLI
 
-Avalanche CLI is a command line tool that gives developers access to everything Avalanche. This release specializes in helping developers develop and test subnets.
+Avalanche CLI is a command line tool that gives developers access to everything Avalanche. This release specializes in helping developers develop and test L1s.
 
 ## Installation
 
@@ -30,21 +30,25 @@ To add it to your path permanently, add an export command to your shell initiali
 
 To download the binary into a specific directory, run:
 
-```
+```sh
 curl -sSfL https://raw.githubusercontent.com/ava-labs/avalanche-cli/main/scripts/install.sh | sh -s -- -b <relative directory>
 ```
 
+## Documentation
+
+Documentation of all available commands can be found in the [Avalanche Documentation](https://docs.avax.network/tooling/avalanche-cli).
+
 ## Dev Container & Codespace
 
 To get started easily, we provide a Dev Container specification, that can be used using GitHub Codespace or locally using Docker and VS Code. [Dev Containers](https://code.visualstudio.com/docs/devcontainers/containers) are a concept that utilizes containerization to create consistent and isolated development environment. You can run them directly on Github by clicking **Code**, switching to the **Codespaces** tab and clicking **Create codespace on main**. Alternatively, you can run them locally with the extensions for [VS Code](https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-containers) or other code editors.
 
 ## Quickstart
 
-After installing, launch your own custom subnet:
+After installing, launch your own custom layer 1:
 
 ```bash
-avalanche subnet create <subnetName>
-avalanche subnet deploy <subnetName>
+avalanche blockchain create <L1Name>
+avalanche blockchain deploy <L1Name>
 ```
 
 Shut down your local deployment with:
@@ -63,32 +67,32 @@ avalanche network start
 
 - Creation of Subnet-EVM, and custom virtual machine subnet configurations
 - Precompile integration and configuration
-- Local deployment of subnets for development and rapid prototyping
-- Fuji Testnet and Avalanche Mainnet deployment of subnets
+- Local deployment of L1s for development and rapid prototyping
+- Fuji Testnet and Avalanche Mainnet deployment of L1s
 - Ledger support
 - Avalanche Package Manager Integration
 
-## Modifying your Subnet Deployment
+## Modifying your L1 Deployment
 
 You can provide a global node config to edit the way your local avalanchego nodes perform under the hood. To provide such a config, you need to create an avalanche-cli config file. By default, a config file is read in from $HOME/.avalanche-cli/config.json If none exists, no error will occur. To provide a config from a custom location, run any command with the flag `--config <pathToConfig>`.
 
 To specify the global node config, provide it as a body for the `node-config` key. Ex:
 
 ```json
 {
-  "network-peer-list-gossip-frequency":"250ms",
-  "network-max-reconnect-delay":"1s",
-  "public-ip":"127.0.0.1",
-  "health-check-frequency":"2s",
-  "api-admin-enabled":true,
-  "api-ipcs-enabled":true,
-  "index-enabled":true
+  "network-peer-list-gossip-frequency": "250ms",
+  "network-max-reconnect-delay": "1s",
+  "public-ip": "127.0.0.1",
+  "health-check-frequency": "2s",
+  "api-admin-enabled": true,
+  "api-ipcs-enabled": true,
+  "index-enabled": true
 }
 ```
 
-### Accessing your local subnet remotely
+### Accessing your local L1 remotely
 
-You may wish to deploy your subnet on a cloud instance and access it remotely. If you'd like to do so, use this as your node config:
+You may wish to deploy your l1 on a cloud instance and access it remotely. If you'd like to do so, use this as your node config:
 
 ```json
 {
@@ -137,38 +141,38 @@ To run the tests, execute the following command from the repo's root directory:
 
 Network snapshots are used by the CLI in order to keep track of blockchain state, and to improve performance of local deployments.
 
-They are the main way to persist subnets, blockchains, and blockchain operations, among different executions of the tool.
+They are the main way to persist blockchains and blockchain operations, among different executions of the tool.
 
 Three different kinds of snapshots are used:
 
 - The `bootstrap snapshot` is provided as the starting network state. It is never modified by CLI usage.
-Designed for fast deploys. Enables full reset of the blockchain state.
+  Designed for fast deploys. Enables full reset of the blockchain state.
 - The `default snapshot` is the main way to keep track of blockchain state. Used by default in the tools.
-It is initialized from the `bootstrap snapshot`, and after that is updated from CLI operations.
+  It is initialized from the `bootstrap snapshot`, and after that is updated from CLI operations.
 - `custom snapshots` can be specified by the user, to save and restore particular states. Only changed if
-explicitly asked to do so.
+  explicitly asked to do so.
 
 ### Local networks
 
 Usage of local networks:
 
 - The local network will be started in the background only if it is not already running
-- If the network is not running, both `network start` and `subnet deploy` will start it from the `default snapshot`.
-`subnet deploy` will also do the deploy on the started network.
-- If the network is running, `network start` will do nothing, and `subnet deploy` will use the running one to do the deploy.
+- If the network is not running, both `network start` and `blockchain deploy` will start it from the `default snapshot`.
+  `blockchain deploy` will also do the deploy on the started network.
+- If the network is running, `network start` will do nothing, and `blockchain deploy` will use the running one to do the deploy.
 - The local network will run until calling `network stop`, `network clean`, or until machine reboot
 
 ### Default snapshot
 
 How the CLI commands affect the `default snapshot`:
 
-- First call of `network start` or `subnet deploy` will initialize `default snapshot` from the `bootstrap snapshot`
-- Subsequent calls to `subnet deploy` do not change the snapshot, only the running network
+- First call of `network start` or `blockchain deploy` will initialize `default snapshot` from the `bootstrap snapshot`
+- Subsequent calls to `blockchain deploy` do not change the snapshot, only the running network
 - `network stop` persist the running network into the `default snapshot`
 - `network clean` copy again the `bootstrap snapshot` into the `default snapshot`, doing a reset of the state
 
 So typically a user will want to do the deploy she needs, change the blockchain state in a specific way, and
-after that execute `network stop` to preserve all the state. In a different session, `network start` or `subnet deploy`
+after that execute `network stop` to preserve all the state. In a different session, `network start` or `blockchain deploy`
 will recover that state.
 
 ### Custom snapshots
@@ -177,14 +181,14 @@ How the CLI commands affect the `custom snapshots`:
 
 - `network stop` can be given an optional snapshot name. This will then be used instead of the default one to save the state
 - `network start` can be given an optional snapshot name. This will then be used instead of the default one to save the state
-- `subnet deploy` will take a running network if it is available, so there is a need to use `network start` previously to do
-deploys, if wanting to use custom snapshots
+- `blockchain deploy` will take a running network if it is available, so there is a need to use `network start` previously to do
+  deploys, if wanting to use custom snapshots
 - `network clean` does not change custom snapshots
 
 So typically a user who wants to use a custom snapshot will do the deploy she needs, change the blockchain state in a specific way, and
 after that execute `network stop` with `--snapshot-name` flag to preserve all the state into the desired snapshot.
 In a different session, `network start` with `--snapshot-name` flag will be called to load that specific snapshot, and after that
-`subnet deploy` can be used on top of it. Notice that you need to continue giving `--snapshot-name` flag to those commands if you
+`blockchain deploy` can be used on top of it. Notice that you need to continue giving `--snapshot-name` flag to those commands if you
 continue saving/restoring to it, if not, `default snapshot will be used`.
 
 ### Snapshots dir
@@ -193,4 +197,4 @@ continue saving/restoring to it, if not, `default snapshot will be used`.
 
 ## Detailed Usage
 
-More detailed information on how to use Avalanche CLI can be found at [here](https://docs.avax.network/subnets/create-a-local-subnet#subnet).
+More detailed information on how to use Avalanche CLI can be found [here](https://docs.avax.network/tooling/avalanche-cli).

VERSION

@@ -1 +1 @@
-1.7.8
+1.8.0

catalog-info.yaml

@@ -4,7 +4,7 @@ metadata:
   name: avalanche-cli
   description: |
     Avalanche-CLI is a command-line interface for building, deploying, and maintaining Avalanche
-    Subnets. It can be used to support the entire Subnet development lifecycle from initial
+    Layer 1s. It can be used to support the entire L1 development lifecycle from initial
     prototyping to production deployments. Avalanche-CLI is available for Linux and Mac, and is open
     source on GitHub.
   annotations:

cmd/backendcmd/spawn_server.go

@@ -13,23 +13,35 @@ import (
 	"github.com/spf13/cobra"
 )
 
-var app *application.Avalanche
+var (
+	app          *application.Avalanche
+	serverPort   string
+	gatewayPort  string
+	snapshotsDir string
+)
 
 // backendCmd is the command to run the backend gRPC process
 func NewCmd(injectedApp *application.Avalanche) *cobra.Command {
 	app = injectedApp
-	return &cobra.Command{
+	cmd := &cobra.Command{
 		Use:    constants.BackendCmd,
 		Short:  "Run the backend server",
 		Long:   "This tool requires a backend process to run; this command starts it",
 		RunE:   startBackend,
 		Args:   cobrautils.ExactArgs(0),
 		Hidden: true,
 	}
+	cmd.Flags().StringVar(&serverPort, "server-port", binutils.LocalNetworkGRPCServerPort, "server port to use")
+	cmd.Flags().StringVar(&gatewayPort, "gateway-port", binutils.LocalNetworkGRPCGatewayPort, "gateway port to use")
+	cmd.Flags().StringVar(&snapshotsDir, "snapshots-dir", "", "snapshots dir to use")
+	return cmd
 }
 
 func startBackend(_ *cobra.Command, _ []string) error {
-	s, err := binutils.NewGRPCServer(app.GetSnapshotsDir())
+	if snapshotsDir == "" {
+		snapshotsDir = app.GetSnapshotsDir()
+	}
+	s, err := binutils.NewGRPCServer(serverPort, gatewayPort, snapshotsDir)
 	if err != nil {
 		return err
 	}