Added basic sample of rewriting CLI integration test in GO

app/app.go

@@ -686,6 +686,13 @@ func New(
 		},
 	)
 
+	app.UpgradeKeeper.SetUpgradeHandler(
+		"v1.4.4",
+		func(ctx sdk.Context, plan upgradetypes.Plan, fromVM module.VersionMap) (module.VersionMap, error) {
+			return app.mm.RunMigrations(ctx, app.configurator, fromVM)
+		},
+	)
+
 	return app
 }
 

deployment/persistent_chains/testnet-2.0/testnet-2.0-csa-endpoints.md

@@ -1,6 +1,6 @@
 # Testnet 2.0 CSA public endpoints
 
-- `REST` - <https://on.test-net.dcl.csa-iot.org>
+[//]: # (- `REST` - <https://on.test-net.dcl.csa-iot.org>)
 - `RPC` - <https://on.test-net.dcl.csa-iot.org:26657>
 - `gRPC` - on.test-net.dcl.csa-iot.org:8443
 - `Seed Node` - 100.25.175.140:26656

docs/design/noc-root-cert-design.md

@@ -96,7 +96,7 @@ Retrieve NOC root certificates associated with a specific VID.
 - CLI Command:
   - `dcld query pki get_noc_x509_root_certs --vid=<uint16>`
 - REST API:
-  - GET `/dcl/pki/noc-root-certificates/{vid}`
+  - GET `/dcl/pki/noc-vid-root-certificates/{vid}`
 
 ### GET_ALL_NOC_X509_ROOT_CERTS
 

docs/pool-upgrade-how-to.md

@@ -60,7 +60,7 @@ One of the trustees proposes the upgrade using the following steps:
       ```
       Please note, that it must be called against the `dcld` binary, not the platform archive itself. So, for Ubuntu, either take a `dcld` binary from the root folder of the release, or extract it from ` dcld.ubuntu.tar.gz`.
 
-   2. Sends [`ProposeUpgrade`](./transactions.md#propose_upgrade) transaction
+   2. Sends [`ProposeUpgrade`](transactions.md#propose_upgrade) transaction
       with the name of the new upgrade handler, the chosen ledger height and the
       info containing URLs of the new application version binaries for supported
       platforms with the calculated checksums.
@@ -92,7 +92,7 @@ Each of them uses the following steps to accomplish this:
          ```
        Please note, that it must be called against the `dcld` binary, not the platform archive itself. So, for Ubuntu, either take a `dcld` binary from the root folder of the release, or extract it from ` dcld.ubuntu.tar.gz`.
 
-2. Sends [`ApproveUpgrade`](./transactions.md#approve_upgrade) transaction
+2. Sends [`ApproveUpgrade`](transactions.md#approve_upgrade) transaction
     with the name of the proposed upgrade.
 
     For example:

docs/pool-upgrade.md

@@ -27,10 +27,10 @@ Any upgrade plan has the following fields:
 ## Workflow
 
 Initially an upgrade plan is proposed by one of trustees using
-[propose-upgrade](./transactions.md#propose_upgrade) command. Then the proposed
+[propose-upgrade](transactions.md) command. Then the proposed
 upgrade plan has to be approved by the majority of trustees (2/3 including the
 trustee who has proposed it) using
-[approve-upgrade](./transactions.md#approve_upgrade) command. When the necessary
+[approve-upgrade](transactions.md#approve_upgrade) command. When the necessary
 count of approvals is gathered, the upgrade plan turns into the approved state
 and is actually scheduled.
 
@@ -81,5 +81,5 @@ checksum when the URL is provided in the specified format. If the downloaded
 file checksum does not equal to the checksum provided in the URL, `go-getter`
 reports that checksums did not match. To view `Info` field value of an upgrade
 plan, just execute an appropriate query command from `dclupgrade` or `upgrade`
-module. See [Upgrade CLI commands reference](./transactions.md#upgrade) for
+module. See [Upgrade CLI commands reference](transactions.md#upgrade) for
 details.