From 1b5f0cb31dfb71011c5ddf270a117ccfcf3c7ad2 Mon Sep 17 00:00:00 2001 From: Liam Aharon Date: Thu, 3 Aug 2023 21:18:26 +0700 Subject: [PATCH 01/16] allow spinning up dev node in background without binary --- Cargo.lock | 2 ++ bin/node-template/node/Cargo.toml | 3 +++ bin/node-template/node/src/command.rs | 1 + bin/node-template/node/src/lib.rs | 6 +++++ test-utils/cli/Cargo.toml | 2 ++ test-utils/cli/src/lib.rs | 37 +++++++++++++++++++++++++++ 6 files changed, 51 insertions(+) create mode 100644 bin/node-template/node/src/lib.rs diff --git a/Cargo.lock b/Cargo.lock index 8effc229ca332..7ecd5f651b39f 100644 --- a/Cargo.lock +++ b/Cargo.lock @@ -11453,7 +11453,9 @@ dependencies = [ "futures", "nix 0.26.2", "node-primitives", + "node-template", "regex", + "sc-cli", "sp-rpc", "substrate-rpc-client", "tokio", diff --git a/bin/node-template/node/Cargo.toml b/bin/node-template/node/Cargo.toml index b05fed96bc8a2..c4e7cf37c3e49 100644 --- a/bin/node-template/node/Cargo.toml +++ b/bin/node-template/node/Cargo.toml @@ -13,6 +13,9 @@ build = "build.rs" [package.metadata.docs.rs] targets = ["x86_64-unknown-linux-gnu"] +[lib] +name = "node_template" + [[bin]] name = "node-template" diff --git a/bin/node-template/node/src/command.rs b/bin/node-template/node/src/command.rs index 8fc697b5f9c14..40f821ac6dc33 100644 --- a/bin/node-template/node/src/command.rs +++ b/bin/node-template/node/src/command.rs @@ -49,6 +49,7 @@ impl SubstrateCli for Cli { } /// Parse and run command line arguments +#[allow(dead_code)] pub fn run() -> sc_cli::Result<()> { let cli = Cli::from_args(); diff --git a/bin/node-template/node/src/lib.rs b/bin/node-template/node/src/lib.rs new file mode 100644 index 0000000000000..c2a26383bd690 --- /dev/null +++ b/bin/node-template/node/src/lib.rs @@ -0,0 +1,6 @@ +mod benchmarking; +mod chain_spec; +pub mod cli; +mod command; +mod rpc; +pub mod service; diff --git a/test-utils/cli/Cargo.toml b/test-utils/cli/Cargo.toml index ac8c519a65cd4..b281325d9baa8 100644 --- a/test-utils/cli/Cargo.toml +++ b/test-utils/cli/Cargo.toml @@ -20,4 +20,6 @@ nix = "0.26.2" regex = "1.7.3" tokio = { version = "1.22.0", features = ["full"] } node-primitives = { path = "../../bin/node/primitives" } +node-template = { path = "../../bin/node-template/node" } +sc-cli = { path = "../../client/cli" } futures = "0.3.28" diff --git a/test-utils/cli/src/lib.rs b/test-utils/cli/src/lib.rs index 7e704b70f8096..7210f4fb6e172 100644 --- a/test-utils/cli/src/lib.rs +++ b/test-utils/cli/src/lib.rs @@ -35,6 +35,43 @@ use std::{ }; use tokio::io::{AsyncBufReadExt, AsyncRead}; +/// Similar to [`crate::start_node`] spawns a dev node on port `45789`, but works in environments +/// where you can't access the substarte binary using `cargo_bin("substrate-node")`. +/// +/// Helpful when you need a Substrate node running in the background in an external project. +/// +/// The downside compared to [`crate::start_node`] is that this function is blocking and has no way +/// of returning a [`Child`]. So you may want to start it inside a new thread. +/// +/// # Example +/// ```ignore +/// // Spawn a dev node in the background. +/// let _ = std::thread::spawn(move || { +/// common::start_node_without_binary(); +/// }); +/// ``` +pub fn start_node_without_binary() { + use sc_cli::SubstrateCli; + + let cli = node_template::cli::Cli::from_iter(vec![ + "node-template", + "--dev", + "--tmp", + "--rpc-port=45789", + ]); + let runner = cli.create_runner(&cli.run).unwrap(); + match runner.run_node_until_exit(|config| async move { + node_template::service::new_full(config).map_err(sc_cli::Error::Service) + }) { + Ok(_) => { + println!("Node process exited successfully."); + }, + Err(e) => { + println!("Node process exited with error: {:?}", e); + }, + }; +} + /// Starts a new Substrate node in development mode with a temporary chain. /// /// This function creates a new Substrate node using the `substrate` binary. From fe8dd35b2b8deae436bf4b083d8c1d495eea0531 Mon Sep 17 00:00:00 2001 From: Liam Aharon Date: Thu, 3 Aug 2023 21:28:36 +0700 Subject: [PATCH 02/16] improve comments --- test-utils/cli/src/lib.rs | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/test-utils/cli/src/lib.rs b/test-utils/cli/src/lib.rs index 7210f4fb6e172..cd0e8a54ede9c 100644 --- a/test-utils/cli/src/lib.rs +++ b/test-utils/cli/src/lib.rs @@ -36,12 +36,13 @@ use std::{ use tokio::io::{AsyncBufReadExt, AsyncRead}; /// Similar to [`crate::start_node`] spawns a dev node on port `45789`, but works in environments -/// where you can't access the substarte binary using `cargo_bin("substrate-node")`. +/// where the substarte binary is not accessible with `cargo_bin("substrate-node")`. /// -/// Helpful when you need a Substrate node running in the background in an external project. +/// Helpful if you need a Substrate dev node running in the background of a project external to +/// `substrate`. /// -/// The downside compared to [`crate::start_node`] is that this function is blocking and has no way -/// of returning a [`Child`]. So you may want to start it inside a new thread. +/// The downside compared to using [`crate::start_node`] is that this method is blocking rather than +/// returning a [`Child`]. Therefore, you may want to call this method inside a new thread. /// /// # Example /// ```ignore From 3ad997fb1e8c817530d1c8c0573db124756434a7 Mon Sep 17 00:00:00 2001 From: Liam Aharon Date: Mon, 7 Aug 2023 15:45:45 +0700 Subject: [PATCH 03/16] restore rust-toolchain --- rust-toolchain | 1 + 1 file changed, 1 insertion(+) create mode 100644 rust-toolchain diff --git a/rust-toolchain b/rust-toolchain new file mode 100644 index 0000000000000..832e9afb6c139 --- /dev/null +++ b/rust-toolchain @@ -0,0 +1 @@ +1.70.0 From 40ba54763d7e5705f5e7b63b4e51353f28bab3da Mon Sep 17 00:00:00 2001 From: Liam Aharon Date: Mon, 7 Aug 2023 15:51:36 +0700 Subject: [PATCH 04/16] remove rust-toolchain --- rust-toolchain | 1 - 1 file changed, 1 deletion(-) delete mode 100644 rust-toolchain diff --git a/rust-toolchain b/rust-toolchain deleted file mode 100644 index 832e9afb6c139..0000000000000 --- a/rust-toolchain +++ /dev/null @@ -1 +0,0 @@ -1.70.0 From d54f2fee7d6846777bf7350420648f69fde3dd9b Mon Sep 17 00:00:00 2001 From: Liam Aharon Date: Tue, 8 Aug 2023 12:49:17 +0700 Subject: [PATCH 05/16] tweak start_node_without_binary api --- Cargo.lock | 1 + test-utils/cli/Cargo.toml | 1 + test-utils/cli/src/lib.rs | 15 +++------------ 3 files changed, 5 insertions(+), 12 deletions(-) diff --git a/Cargo.lock b/Cargo.lock index 7ecd5f651b39f..1396c1b033567 100644 --- a/Cargo.lock +++ b/Cargo.lock @@ -11456,6 +11456,7 @@ dependencies = [ "node-template", "regex", "sc-cli", + "sc-service", "sp-rpc", "substrate-rpc-client", "tokio", diff --git a/test-utils/cli/Cargo.toml b/test-utils/cli/Cargo.toml index b281325d9baa8..7a0abf524f7be 100644 --- a/test-utils/cli/Cargo.toml +++ b/test-utils/cli/Cargo.toml @@ -22,4 +22,5 @@ tokio = { version = "1.22.0", features = ["full"] } node-primitives = { path = "../../bin/node/primitives" } node-template = { path = "../../bin/node-template/node" } sc-cli = { path = "../../client/cli" } +sc-service = { path = "../../client/service" } futures = "0.3.28" diff --git a/test-utils/cli/src/lib.rs b/test-utils/cli/src/lib.rs index cd0e8a54ede9c..5968e6c767590 100644 --- a/test-utils/cli/src/lib.rs +++ b/test-utils/cli/src/lib.rs @@ -51,26 +51,17 @@ use tokio::io::{AsyncBufReadExt, AsyncRead}; /// common::start_node_without_binary(); /// }); /// ``` -pub fn start_node_without_binary() { +pub fn start_node_without_binary() -> Result<(), sc_service::error::Error> { use sc_cli::SubstrateCli; let cli = node_template::cli::Cli::from_iter(vec![ - "node-template", + "node-template", // first arg is ignored, this could be anything. "--dev", "--tmp", "--rpc-port=45789", ]); let runner = cli.create_runner(&cli.run).unwrap(); - match runner.run_node_until_exit(|config| async move { - node_template::service::new_full(config).map_err(sc_cli::Error::Service) - }) { - Ok(_) => { - println!("Node process exited successfully."); - }, - Err(e) => { - println!("Node process exited with error: {:?}", e); - }, - }; + runner.run_node_until_exit(|config| async move { node_template::service::new_full(config) }) } /// Starts a new Substrate node in development mode with a temporary chain. From 8c281928b2c34761f0622f992b9cdd91f4f6b11d Mon Sep 17 00:00:00 2001 From: Liam Aharon Date: Tue, 8 Aug 2023 17:39:59 +1000 Subject: [PATCH 06/16] Update test-utils/cli/src/lib.rs Co-authored-by: Alexandru Vasile <60601340+lexnv@users.noreply.github.com> --- test-utils/cli/src/lib.rs | 1 - 1 file changed, 1 deletion(-) diff --git a/test-utils/cli/src/lib.rs b/test-utils/cli/src/lib.rs index 5968e6c767590..b0c30cb9d4d9f 100644 --- a/test-utils/cli/src/lib.rs +++ b/test-utils/cli/src/lib.rs @@ -57,7 +57,6 @@ pub fn start_node_without_binary() -> Result<(), sc_service::error::Error> { let cli = node_template::cli::Cli::from_iter(vec![ "node-template", // first arg is ignored, this could be anything. "--dev", - "--tmp", "--rpc-port=45789", ]); let runner = cli.create_runner(&cli.run).unwrap(); From fbd585fd1d9dca691b1ebb05ec16d286c0189d0f Mon Sep 17 00:00:00 2001 From: Liam Aharon Date: Tue, 8 Aug 2023 14:52:56 +0700 Subject: [PATCH 07/16] address commends --- test-utils/cli/src/lib.rs | 18 ++++++++---------- 1 file changed, 8 insertions(+), 10 deletions(-) diff --git a/test-utils/cli/src/lib.rs b/test-utils/cli/src/lib.rs index 5968e6c767590..83573c2ed65f1 100644 --- a/test-utils/cli/src/lib.rs +++ b/test-utils/cli/src/lib.rs @@ -35,8 +35,9 @@ use std::{ }; use tokio::io::{AsyncBufReadExt, AsyncRead}; -/// Similar to [`crate::start_node`] spawns a dev node on port `45789`, but works in environments -/// where the substarte binary is not accessible with `cargo_bin("substrate-node")`. +/// Similar to [`crate::start_node`] spawns a node, but works in environments where the substarte +/// binary is not accessible with `cargo_bin("substrate-node")` and allows customising the args +/// passed in. /// /// Helpful if you need a Substrate dev node running in the background of a project external to /// `substrate`. @@ -48,18 +49,15 @@ use tokio::io::{AsyncBufReadExt, AsyncRead}; /// ```ignore /// // Spawn a dev node in the background. /// let _ = std::thread::spawn(move || { -/// common::start_node_without_binary(); +/// common::start_node_inline(vec!["--dev", "--rpc-port=45789"]); /// }); /// ``` -pub fn start_node_without_binary() -> Result<(), sc_service::error::Error> { +pub fn start_node_inline(args: Vec) -> Result<(), sc_service::error::Error> { use sc_cli::SubstrateCli; - let cli = node_template::cli::Cli::from_iter(vec![ - "node-template", // first arg is ignored, this could be anything. - "--dev", - "--tmp", - "--rpc-port=45789", - ]); + // Prepend the args with some dummy value because the first arg is skipped. + let cli_call = std::iter::once("node-template".to_string()).chain(args); + let cli = node_template::cli::Cli::from_iter(cli_call); let runner = cli.create_runner(&cli.run).unwrap(); runner.run_node_until_exit(|config| async move { node_template::service::new_full(config) }) } From 2c05aed3b88ca82d950848f52ae8e8d3eaf4104b Mon Sep 17 00:00:00 2001 From: Liam Aharon Date: Tue, 8 Aug 2023 14:57:09 +0700 Subject: [PATCH 08/16] use &str --- test-utils/cli/src/lib.rs | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/test-utils/cli/src/lib.rs b/test-utils/cli/src/lib.rs index 83573c2ed65f1..39ce29c5bab55 100644 --- a/test-utils/cli/src/lib.rs +++ b/test-utils/cli/src/lib.rs @@ -52,11 +52,11 @@ use tokio::io::{AsyncBufReadExt, AsyncRead}; /// common::start_node_inline(vec!["--dev", "--rpc-port=45789"]); /// }); /// ``` -pub fn start_node_inline(args: Vec) -> Result<(), sc_service::error::Error> { +pub fn start_node_inline(args: Vec<&str>) -> Result<(), sc_service::error::Error> { use sc_cli::SubstrateCli; // Prepend the args with some dummy value because the first arg is skipped. - let cli_call = std::iter::once("node-template".to_string()).chain(args); + let cli_call = std::iter::once("node-template").chain(args); let cli = node_template::cli::Cli::from_iter(cli_call); let runner = cli.create_runner(&cli.run).unwrap(); runner.run_node_until_exit(|config| async move { node_template::service::new_full(config) }) From 6d42a7ab1eb77df8cea679426439b6a1bc11d9d3 Mon Sep 17 00:00:00 2001 From: Liam Aharon Date: Tue, 8 Aug 2023 15:01:10 +0700 Subject: [PATCH 09/16] update example --- test-utils/cli/src/lib.rs | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/test-utils/cli/src/lib.rs b/test-utils/cli/src/lib.rs index 39ce29c5bab55..f695cf02593cb 100644 --- a/test-utils/cli/src/lib.rs +++ b/test-utils/cli/src/lib.rs @@ -47,9 +47,14 @@ use tokio::io::{AsyncBufReadExt, AsyncRead}; /// /// # Example /// ```ignore -/// // Spawn a dev node in the background. +/// // Spawn a dev node. /// let _ = std::thread::spawn(move || { -/// common::start_node_inline(vec!["--dev", "--rpc-port=45789"]); +/// match common::start_node_inline(vec!["--dev", "--rpc-port=12345"]) { +/// Ok(_) => {} +/// Err(e) => { +/// panic!("Node exited with error: {}", e); +/// } +/// } /// }); /// ``` pub fn start_node_inline(args: Vec<&str>) -> Result<(), sc_service::error::Error> { From a5cb42651fb8c6761d8ce0656b08714208e1b622 Mon Sep 17 00:00:00 2001 From: Liam Aharon Date: Tue, 8 Aug 2023 15:09:57 +0700 Subject: [PATCH 10/16] update comment --- test-utils/cli/src/lib.rs | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/test-utils/cli/src/lib.rs b/test-utils/cli/src/lib.rs index f695cf02593cb..ee270ab3667b2 100644 --- a/test-utils/cli/src/lib.rs +++ b/test-utils/cli/src/lib.rs @@ -35,8 +35,8 @@ use std::{ }; use tokio::io::{AsyncBufReadExt, AsyncRead}; -/// Similar to [`crate::start_node`] spawns a node, but works in environments where the substarte -/// binary is not accessible with `cargo_bin("substrate-node")` and allows customising the args +/// Similar to [`crate::start_node`] spawns a node, but works in environments where the substrate +/// binary is not accessible with `cargo_bin("substrate-node")`, and allows customising the args /// passed in. /// /// Helpful if you need a Substrate dev node running in the background of a project external to From e18677f081247dd9672f64ea34d2c651daf401c2 Mon Sep 17 00:00:00 2001 From: Liam Aharon Date: Tue, 8 Aug 2023 15:37:45 +0700 Subject: [PATCH 11/16] update docs --- utils/frame/try-runtime/cli/src/lib.rs | 334 +------------------------ 1 file changed, 3 insertions(+), 331 deletions(-) diff --git a/utils/frame/try-runtime/cli/src/lib.rs b/utils/frame/try-runtime/cli/src/lib.rs index fbc55ad1dce6f..c316692d0810c 100644 --- a/utils/frame/try-runtime/cli/src/lib.rs +++ b/utils/frame/try-runtime/cli/src/lib.rs @@ -17,338 +17,10 @@ //! # Try-runtime //! -//! Substrate's ultimate testing framework for the power users. +//! Substrate's `try-runtime` subcommand has been migrated to a [standalone +//! CLI](https://github.com/paritytech/try-runtime-cli). //! -//! > As the name suggests, `try-runtime` is a detailed testing framework that gives you a lot of -//! control over what is being executed in which environment. It is recommended that user's first -//! familiarize themselves with substrate in depth, particularly the execution model. It is critical -//! to deeply understand how the wasm/client/runtime interactions, and the runtime apis work in the -//! substrate runtime, before commencing to working with `try-runtime`. -//! -//! #### Resources -//! -//! Some resources about the above: -//! -//! 1. -//! 2. -//! 3. -//! -//! --- -//! -//! ## Background Knowledge -//! -//! The basis of all try-runtime commands is the same: connect to a live node, scrape its *state* -//! and put it inside a `TestExternalities`, then call into a *specific runtime-api* using the given -//! state and some *runtime*. -//! -//! Alternatively, the state could come from a snapshot file. -//! -//! All of the variables in the above statement are made *italic*. Let's look at each of them: -//! -//! 1. **State** is the key-value pairs of data that comprise the canonical information that any -//! blockchain is keeping. A state can be full (all key-value pairs), or be partial (only pairs -//! related to some pallets/prefixes). Moreover, some keys are especial and are not related to -//! specific pallets, known as [`well_known_keys`] in substrate. The most important of these is -//! the `:CODE:` key, which contains the code used for execution, when wasm execution is chosen. -//! -//! 2. *A runtime-api* call is a call into a function defined in the runtime, *on top of a given -//! state*. Each subcommand of `try-runtime` utilizes a specific *runtime-api*. -//! -//! 3. Finally, the **runtime** is the actual code that is used to execute the aforementioned -//! runtime-api. Everything in this crate assumes wasm execution, which means the runtime that -//! you use is the one stored onchain, namely under the `:CODE:` key. -//! -//! To recap, a typical try-runtime command does the following: -//! -//! 1. Download the state of a live chain, and write to an `externalities`. -//! 2. Overwrite the `:CODE:` with a given wasm blob -//! 3. Test some functionality via calling a runtime-api. -//! -//! ## Usage -//! -//! To use any of the provided commands, [`SharedParams`] must be provided. The most important of -//! which being [`SharedParams::runtime`], which specifies which runtime to use. Furthermore, -//! [`SharedParams::overwrite_state_version`] can be used to alter the state-version (see -//! for more info). -//! -//! Then, the specific command has to be specified. See [`Command`] for more information about each -//! command's specific customization flags, and assumptions regarding the runtime being used. -//! -//! Said briefly, this CLI is capable of executing: -//! -//! * [`Command::OnRuntimeUpgrade`]: execute all the `on_runtime_upgrade` hooks. -//! * [`Command::ExecuteBlock`]: re-execute the given block. -//! * [`Command::OffchainWorker`]: re-execute the given block's offchain worker code path. -//! * [`Command::FollowChain`]: continuously execute the blocks of a remote chain on top of a given -//! runtime. -//! * [`Command::CreateSnapshot`]: Create a snapshot file from a remote node. -//! -//! Finally, To make sure there are no errors regarding this, always run any `try-runtime` command -//! with `executor=trace` logging targets, which will specify which runtime is being used per api -//! call. Moreover, `remote-ext`, `try-runtime` and `runtime` logs targets will also be useful. -//! -//! ## Spec name check -//! -//! A common pitfall is that you might be running some test on top of the state of chain `x`, with -//! the runtime of chain `y`. To avoid this all commands do a spec-name check before executing -//! anything by default. This will check the, if any alterations are being made to the `:CODE:`, -//! then the spec names match. The spec versions are warned, but are not mandated to match. -//! -//! > If anything, in most cases, we expect spec-versions to NOT match, because try-runtime is all -//! > about testing unreleased runtimes. -//! -//! ## Note on signature and state-root checks -//! -//! All of the commands calling into `TryRuntime_execute_block` ([`Command::ExecuteBlock`] and -//! [`Command::FollowChain`]) disable both state root and signature checks. This is because in 99% -//! of the cases, the runtime that is being tested is different from the one that is stored in the -//! canonical chain state. This implies: -//! -//! 1. the state root will NEVER match, because `:CODE:` is different between the two. -//! 2. replaying all transactions will fail, because the spec-version is part of the transaction -//! signature. -//! -//! ## Best Practices -//! -//! Try-runtime is all about battle-testing unreleased runtime. The following list of suggestions -//! help developers maximize the testing coverage and make base use of `try-runtime`. -//! -//! #### Adding pre/post hooks -//! -//! One of the gems that come only in the `try-runtime` feature flag is the `pre_upgrade` and -//! `post_upgrade` hooks for `OnRuntimeUpgrade`. This trait is implemented either inside the pallet, -//! or manually in a runtime, to define a migration. In both cases, these functions can be added, -//! given the right flag: -//! -//! ```ignore -//! #[cfg(feature = "try-runtime")] -//! fn pre_upgrade() -> Result, TryRuntimeError> {} -//! -//! #[cfg(feature = "try-runtime")] -//! fn post_upgrade(state: Vec) -> Result<(), TryRuntimeError> {} -//! ``` -//! -//! (The pallet macro syntax will support this simply as a part of `#[pallet::hooks]`). -//! -//! These hooks allow you to execute some code, only within the `on-runtime-upgrade` command, before -//! and after the migration. Moreover, `pre_upgrade` can return a `Vec` that contains arbitrary -//! encoded data (usually some pre-upgrade state) which will be passed to `post_upgrade` after -//! upgrading and used for post checking. -//! -//! ## State Consistency -//! -//! Similarly, each pallet can expose a function in `#[pallet::hooks]` section as follows: -//! -//! ```ignore -//! #[cfg(feature = "try-runtime")] -//! fn try_state(_: BlockNumber) -> Result<(), TryRuntimeError> {} -//! ``` -//! -//! which is called on numerous code paths in the try-runtime tool. These checks should ensure that -//! the state of the pallet is consistent and correct. See `frame_support::try_runtime::TryState` -//! for more info. -//! -//! #### Logging -//! -//! It is super helpful to make sure your migration code uses logging (always with a `runtime` log -//! target prefix, e.g. `runtime::balance`) and state exactly at which stage it is, and what it is -//! doing. -//! -//! #### Guarding migrations -//! -//! Always make sure that any migration code is guarded either by `StorageVersion`, or by some -//! custom storage item, so that it is NEVER executed twice, even if the code lives in two -//! consecutive runtimes. -//! -//! ## Examples -//! -//! For the following examples, we assume the existence of the following: -//! -//! 1. a substrate node compiled without `--feature try-runtime`, called `substrate`. This will be -//! the running node that you connect to. then, after some changes to this node, you compile it with -//! `--features try-runtime`. This gives you: -//! 2. a substrate binary that has the try-runtime sub-command enabled. -//! 3. a wasm blob that has try-runtime functionality. -//! -//! ```bash -//! # this is like your running deployed node. -//! cargo build --release && cp target/release/substrate . -//! -//! # this is like your WIP branch. -//! cargo build --release --features try-runtime -//! cp target/release/substrate substrate-try-runtime -//! cp ./target/release/wbuild/kitchensink-runtime/kitchensink_runtime.wasm runtime-try-runtime.wasm -//! ``` -//! -//! > The above example is with `substrate`'s `kitchensink-runtime`, but is applicable to any -//! > substrate-based chain that has implemented `try-runtime-cli`. -//! -//! * If you run `try-runtime` subcommand against `substrate` binary listed above, you get the -//! following error. -//! -//! ```bash -//! [substrate] ./substrate try-runtime -//! Error: Input("TryRuntime wasn't enabled when building the node. You can enable it with `--features try-runtime`.") -//! ``` -//! -//! * If you run the same against `substrate-try-runtime`, it will work. -//! -//! ```bash -//! [substrate] ./substrate-try-runtime try-runtime -//! Try some command against runtime state -//! -//! Usage: substrate-try-runtime try-runtime [OPTIONS] --runtime -//! -//! Commands: -//! on-runtime-upgrade Execute the migrations of the "local runtime" -//! execute-block Executes the given block against some state -//! offchain-worker Executes *the offchain worker hooks* of a given block against some state -//! follow-chain Follow the given chain's finalized blocks and apply all of its extrinsics -//! create-snapshot Create a new snapshot file -//! help Print this message or the help of the given subcommand(s) -//! -//! Options: -//! --chain -//! Specify the chain specification -//! --dev -//! Specify the development chain -//! -d, --base-path -//! Specify custom base path -//! -l, --log ... -//! Sets a custom logging filter. Syntax is `=`, e.g. -lsync=debug -//! --detailed-log-output -//! Enable detailed log output -//! --disable-log-color -//! Disable log color output -//! --enable-log-reloading -//! Enable feature to dynamically update and reload the log filter -//! --tracing-targets -//! Sets a custom profiling filter. Syntax is the same as for logging: `=` -//! --tracing-receiver -//! Receiver to process tracing messages [default: log] [possible values: log] -//! --runtime -//! The runtime to use -//! --wasm-execution -//! Type of wasm execution used [default: compiled] [possible values: interpreted-i-know-what-i-do, compiled] -//! --wasm-instantiation-strategy -//! The WASM instantiation method to use [default: pooling-copy-on-write] [possible values: pooling-copy-on-write, recreate-instance-copy-on-write, pooling, recreate-instance, legacy-instance-reuse] -//! --heap-pages -//! The number of 64KB pages to allocate for Wasm execution. Defaults to [`sc_service::Configuration.default_heap_pages`] -//! --overwrite-state-version -//! Overwrite the `state_version` -//! -h, --help -//! Print help information (use `--help` for more detail) -//! -V, --version -//! Print version information -//! ``` -//! -//! * Run the migrations of a given runtime on top of a live state. -//! -//! ```bash -//! # assuming there's `./substrate --dev --tmp --ws-port 9999` or similar running. -//! ./substrate-try-runtime \ -//! try-runtime \ -//! --runtime runtime-try-runtime.wasm \ -//! -lruntime=debug \ -//! on-runtime-upgrade \ -//! live --uri ws://localhost:9999 -//! ``` -//! -//! * Same as the previous one, but run it at specific block number's state. This means that this -//! block hash's state shall not yet have been pruned in `rpc.polkadot.io`. -//! -//! ```bash -//! ./substrate-try-runtime \ -//! try-runtime \ -//! --runtime runtime-try-runtime.wasm \ -//! -lruntime=debug \ -//! on-runtime-upgrade \ -//! live --uri ws://localhost:9999 \ -//! # replace with your desired block hash! -//! --at 0xa1b16c1efd889a9f17375ec4dd5c1b4351a2be17fa069564fced10d23b9b3836 -//! ``` -//! -//! * Executing the same command with the [`Runtime::Existing`] will fail because the existing -//! runtime, stored onchain in `substrate` binary that we compiled earlier does not have -//! `try-runtime` feature! -//! -//! ```bash -//! ./substrate-try-runtime try-runtime --runtime existing -lruntime=debug on-runtime-upgrade live --uri ws://localhost:9999 -//! ... -//! Error: Input("given runtime is NOT compiled with try-runtime feature!") -//! ``` -//! -//! * Now, let's use a snapshot file. First, we create the snapshot: -//! -//! ```bash -//! ./substrate-try-runtime try-runtime --runtime existing -lruntime=debug create-snapshot --uri ws://localhost:9999 -//! 2022-12-13 10:28:17.516 INFO main try-runtime::cli: snapshot path not provided (-s), using 'node-268@latest.snap' -//! 2022-12-13 10:28:17.516 INFO main remote-ext: since no at is provided, setting it to latest finalized head, 0xe7d0b614dfe89af65b33577aae46a6f958c974bf52f8a5e865a0f4faeb578d22 -//! 2022-12-13 10:28:17.516 INFO main remote-ext: since no prefix is filtered, the data for all pallets will be downloaded -//! 2022-12-13 10:28:17.550 INFO main remote-ext: writing snapshot of 1611464 bytes to "node-268@latest.snap" -//! 2022-12-13 10:28:17.551 INFO main remote-ext: initialized state externalities with storage root 0x925e4e95de4c08474fb7f976c4472fa9b8a1091619cd7820a793bf796ee6d932 and state_version V1 -//! ``` -//! -//! > Note that the snapshot contains the `existing` runtime, which does not have the correct -//! > `try-runtime` feature. In the following commands, we still need to overwrite the runtime. -//! -//! Then, we can use it to have the same command as before, `on-runtime-upgrade` -//! -//! ```bash -//! ./substrate-try-runtime try-runtime \ -//! --runtime runtime-try-runtime.wasm \ -//! -lruntime=debug \ -//! on-runtime-upgrade \ -//! snap -s node-268@latest.snap -//! ``` -//! -//! * Execute the latest finalized block with the given runtime. -//! -//! ```bash -//! ./substrate-try-runtime try-runtime \ -//! --runtime runtime-try-runtime.wasm \ -//! -lruntime=debug \ -//! execute-block live \ -//! --uri ws://localhost:9999 -//! ``` -//! -//! This can still be customized at a given block with `--at`. If you want to use a snapshot, you -//! can still use `--block-ws-uri` to provide a node form which the block data can be fetched. -//! -//! Moreover, this runs the `frame_support::try_runtime::TryState` hooks as well. The hooks to run -//! can be customized with the `--try-state`. For example: -//! -//! ```bash -//! ./substrate-try-runtime try-runtime \ -//! --runtime runtime-try-runtime.wasm \ -//! -lruntime=debug \ -//! execute-block \ -//! --try-state System,Staking \ -//! live \ -//! --uri ws://localhost:9999 \ -//! --pallet System Staking -//! ``` -//! -//! Will only run the `try-state` of the two given pallets. When running `try-state` against -//! some real chain data it can take a long time for the command to execute since it has to -//! query all the key-value pairs. In scenarios like above where we only want to run the -//! `try-state` for some specific pallets, we can use the `--pallet` option to specify from -//! which pallets we want to query the state. This will greatly decrease the execution time. -//! -//! See [`frame_try_runtime::TryStateSelect`] for more information. -//! -//! * Follow our live chain's blocks using `follow-chain`, whilst running the try-state of 3 pallets -//! in a round robin fashion -//! -//! ```bash -//! ./substrate-try-runtime \ -//! try-runtime \ -//! --runtime runtime-try-runtime.wasm \ -//! -lruntime=debug \ -//! follow-chain \ -//! --uri ws://localhost:9999 \ -//! --try-state rr-3 -//! ``` +//! It is no longer maintained here and will be removed in the future. #![cfg(feature = "try-runtime")] From 6b3615501110666621f49f1ef11e0f19576b1c78 Mon Sep 17 00:00:00 2001 From: Liam Aharon Date: Tue, 8 Aug 2023 15:38:53 +0700 Subject: [PATCH 12/16] Revert "update docs" This reverts commit e18677f081247dd9672f64ea34d2c651daf401c2. --- utils/frame/try-runtime/cli/src/lib.rs | 334 ++++++++++++++++++++++++- 1 file changed, 331 insertions(+), 3 deletions(-) diff --git a/utils/frame/try-runtime/cli/src/lib.rs b/utils/frame/try-runtime/cli/src/lib.rs index c316692d0810c..fbc55ad1dce6f 100644 --- a/utils/frame/try-runtime/cli/src/lib.rs +++ b/utils/frame/try-runtime/cli/src/lib.rs @@ -17,10 +17,338 @@ //! # Try-runtime //! -//! Substrate's `try-runtime` subcommand has been migrated to a [standalone -//! CLI](https://github.com/paritytech/try-runtime-cli). +//! Substrate's ultimate testing framework for the power users. //! -//! It is no longer maintained here and will be removed in the future. +//! > As the name suggests, `try-runtime` is a detailed testing framework that gives you a lot of +//! control over what is being executed in which environment. It is recommended that user's first +//! familiarize themselves with substrate in depth, particularly the execution model. It is critical +//! to deeply understand how the wasm/client/runtime interactions, and the runtime apis work in the +//! substrate runtime, before commencing to working with `try-runtime`. +//! +//! #### Resources +//! +//! Some resources about the above: +//! +//! 1. +//! 2. +//! 3. +//! +//! --- +//! +//! ## Background Knowledge +//! +//! The basis of all try-runtime commands is the same: connect to a live node, scrape its *state* +//! and put it inside a `TestExternalities`, then call into a *specific runtime-api* using the given +//! state and some *runtime*. +//! +//! Alternatively, the state could come from a snapshot file. +//! +//! All of the variables in the above statement are made *italic*. Let's look at each of them: +//! +//! 1. **State** is the key-value pairs of data that comprise the canonical information that any +//! blockchain is keeping. A state can be full (all key-value pairs), or be partial (only pairs +//! related to some pallets/prefixes). Moreover, some keys are especial and are not related to +//! specific pallets, known as [`well_known_keys`] in substrate. The most important of these is +//! the `:CODE:` key, which contains the code used for execution, when wasm execution is chosen. +//! +//! 2. *A runtime-api* call is a call into a function defined in the runtime, *on top of a given +//! state*. Each subcommand of `try-runtime` utilizes a specific *runtime-api*. +//! +//! 3. Finally, the **runtime** is the actual code that is used to execute the aforementioned +//! runtime-api. Everything in this crate assumes wasm execution, which means the runtime that +//! you use is the one stored onchain, namely under the `:CODE:` key. +//! +//! To recap, a typical try-runtime command does the following: +//! +//! 1. Download the state of a live chain, and write to an `externalities`. +//! 2. Overwrite the `:CODE:` with a given wasm blob +//! 3. Test some functionality via calling a runtime-api. +//! +//! ## Usage +//! +//! To use any of the provided commands, [`SharedParams`] must be provided. The most important of +//! which being [`SharedParams::runtime`], which specifies which runtime to use. Furthermore, +//! [`SharedParams::overwrite_state_version`] can be used to alter the state-version (see +//! for more info). +//! +//! Then, the specific command has to be specified. See [`Command`] for more information about each +//! command's specific customization flags, and assumptions regarding the runtime being used. +//! +//! Said briefly, this CLI is capable of executing: +//! +//! * [`Command::OnRuntimeUpgrade`]: execute all the `on_runtime_upgrade` hooks. +//! * [`Command::ExecuteBlock`]: re-execute the given block. +//! * [`Command::OffchainWorker`]: re-execute the given block's offchain worker code path. +//! * [`Command::FollowChain`]: continuously execute the blocks of a remote chain on top of a given +//! runtime. +//! * [`Command::CreateSnapshot`]: Create a snapshot file from a remote node. +//! +//! Finally, To make sure there are no errors regarding this, always run any `try-runtime` command +//! with `executor=trace` logging targets, which will specify which runtime is being used per api +//! call. Moreover, `remote-ext`, `try-runtime` and `runtime` logs targets will also be useful. +//! +//! ## Spec name check +//! +//! A common pitfall is that you might be running some test on top of the state of chain `x`, with +//! the runtime of chain `y`. To avoid this all commands do a spec-name check before executing +//! anything by default. This will check the, if any alterations are being made to the `:CODE:`, +//! then the spec names match. The spec versions are warned, but are not mandated to match. +//! +//! > If anything, in most cases, we expect spec-versions to NOT match, because try-runtime is all +//! > about testing unreleased runtimes. +//! +//! ## Note on signature and state-root checks +//! +//! All of the commands calling into `TryRuntime_execute_block` ([`Command::ExecuteBlock`] and +//! [`Command::FollowChain`]) disable both state root and signature checks. This is because in 99% +//! of the cases, the runtime that is being tested is different from the one that is stored in the +//! canonical chain state. This implies: +//! +//! 1. the state root will NEVER match, because `:CODE:` is different between the two. +//! 2. replaying all transactions will fail, because the spec-version is part of the transaction +//! signature. +//! +//! ## Best Practices +//! +//! Try-runtime is all about battle-testing unreleased runtime. The following list of suggestions +//! help developers maximize the testing coverage and make base use of `try-runtime`. +//! +//! #### Adding pre/post hooks +//! +//! One of the gems that come only in the `try-runtime` feature flag is the `pre_upgrade` and +//! `post_upgrade` hooks for `OnRuntimeUpgrade`. This trait is implemented either inside the pallet, +//! or manually in a runtime, to define a migration. In both cases, these functions can be added, +//! given the right flag: +//! +//! ```ignore +//! #[cfg(feature = "try-runtime")] +//! fn pre_upgrade() -> Result, TryRuntimeError> {} +//! +//! #[cfg(feature = "try-runtime")] +//! fn post_upgrade(state: Vec) -> Result<(), TryRuntimeError> {} +//! ``` +//! +//! (The pallet macro syntax will support this simply as a part of `#[pallet::hooks]`). +//! +//! These hooks allow you to execute some code, only within the `on-runtime-upgrade` command, before +//! and after the migration. Moreover, `pre_upgrade` can return a `Vec` that contains arbitrary +//! encoded data (usually some pre-upgrade state) which will be passed to `post_upgrade` after +//! upgrading and used for post checking. +//! +//! ## State Consistency +//! +//! Similarly, each pallet can expose a function in `#[pallet::hooks]` section as follows: +//! +//! ```ignore +//! #[cfg(feature = "try-runtime")] +//! fn try_state(_: BlockNumber) -> Result<(), TryRuntimeError> {} +//! ``` +//! +//! which is called on numerous code paths in the try-runtime tool. These checks should ensure that +//! the state of the pallet is consistent and correct. See `frame_support::try_runtime::TryState` +//! for more info. +//! +//! #### Logging +//! +//! It is super helpful to make sure your migration code uses logging (always with a `runtime` log +//! target prefix, e.g. `runtime::balance`) and state exactly at which stage it is, and what it is +//! doing. +//! +//! #### Guarding migrations +//! +//! Always make sure that any migration code is guarded either by `StorageVersion`, or by some +//! custom storage item, so that it is NEVER executed twice, even if the code lives in two +//! consecutive runtimes. +//! +//! ## Examples +//! +//! For the following examples, we assume the existence of the following: +//! +//! 1. a substrate node compiled without `--feature try-runtime`, called `substrate`. This will be +//! the running node that you connect to. then, after some changes to this node, you compile it with +//! `--features try-runtime`. This gives you: +//! 2. a substrate binary that has the try-runtime sub-command enabled. +//! 3. a wasm blob that has try-runtime functionality. +//! +//! ```bash +//! # this is like your running deployed node. +//! cargo build --release && cp target/release/substrate . +//! +//! # this is like your WIP branch. +//! cargo build --release --features try-runtime +//! cp target/release/substrate substrate-try-runtime +//! cp ./target/release/wbuild/kitchensink-runtime/kitchensink_runtime.wasm runtime-try-runtime.wasm +//! ``` +//! +//! > The above example is with `substrate`'s `kitchensink-runtime`, but is applicable to any +//! > substrate-based chain that has implemented `try-runtime-cli`. +//! +//! * If you run `try-runtime` subcommand against `substrate` binary listed above, you get the +//! following error. +//! +//! ```bash +//! [substrate] ./substrate try-runtime +//! Error: Input("TryRuntime wasn't enabled when building the node. You can enable it with `--features try-runtime`.") +//! ``` +//! +//! * If you run the same against `substrate-try-runtime`, it will work. +//! +//! ```bash +//! [substrate] ./substrate-try-runtime try-runtime +//! Try some command against runtime state +//! +//! Usage: substrate-try-runtime try-runtime [OPTIONS] --runtime +//! +//! Commands: +//! on-runtime-upgrade Execute the migrations of the "local runtime" +//! execute-block Executes the given block against some state +//! offchain-worker Executes *the offchain worker hooks* of a given block against some state +//! follow-chain Follow the given chain's finalized blocks and apply all of its extrinsics +//! create-snapshot Create a new snapshot file +//! help Print this message or the help of the given subcommand(s) +//! +//! Options: +//! --chain +//! Specify the chain specification +//! --dev +//! Specify the development chain +//! -d, --base-path +//! Specify custom base path +//! -l, --log ... +//! Sets a custom logging filter. Syntax is `=`, e.g. -lsync=debug +//! --detailed-log-output +//! Enable detailed log output +//! --disable-log-color +//! Disable log color output +//! --enable-log-reloading +//! Enable feature to dynamically update and reload the log filter +//! --tracing-targets +//! Sets a custom profiling filter. Syntax is the same as for logging: `=` +//! --tracing-receiver +//! Receiver to process tracing messages [default: log] [possible values: log] +//! --runtime +//! The runtime to use +//! --wasm-execution +//! Type of wasm execution used [default: compiled] [possible values: interpreted-i-know-what-i-do, compiled] +//! --wasm-instantiation-strategy +//! The WASM instantiation method to use [default: pooling-copy-on-write] [possible values: pooling-copy-on-write, recreate-instance-copy-on-write, pooling, recreate-instance, legacy-instance-reuse] +//! --heap-pages +//! The number of 64KB pages to allocate for Wasm execution. Defaults to [`sc_service::Configuration.default_heap_pages`] +//! --overwrite-state-version +//! Overwrite the `state_version` +//! -h, --help +//! Print help information (use `--help` for more detail) +//! -V, --version +//! Print version information +//! ``` +//! +//! * Run the migrations of a given runtime on top of a live state. +//! +//! ```bash +//! # assuming there's `./substrate --dev --tmp --ws-port 9999` or similar running. +//! ./substrate-try-runtime \ +//! try-runtime \ +//! --runtime runtime-try-runtime.wasm \ +//! -lruntime=debug \ +//! on-runtime-upgrade \ +//! live --uri ws://localhost:9999 +//! ``` +//! +//! * Same as the previous one, but run it at specific block number's state. This means that this +//! block hash's state shall not yet have been pruned in `rpc.polkadot.io`. +//! +//! ```bash +//! ./substrate-try-runtime \ +//! try-runtime \ +//! --runtime runtime-try-runtime.wasm \ +//! -lruntime=debug \ +//! on-runtime-upgrade \ +//! live --uri ws://localhost:9999 \ +//! # replace with your desired block hash! +//! --at 0xa1b16c1efd889a9f17375ec4dd5c1b4351a2be17fa069564fced10d23b9b3836 +//! ``` +//! +//! * Executing the same command with the [`Runtime::Existing`] will fail because the existing +//! runtime, stored onchain in `substrate` binary that we compiled earlier does not have +//! `try-runtime` feature! +//! +//! ```bash +//! ./substrate-try-runtime try-runtime --runtime existing -lruntime=debug on-runtime-upgrade live --uri ws://localhost:9999 +//! ... +//! Error: Input("given runtime is NOT compiled with try-runtime feature!") +//! ``` +//! +//! * Now, let's use a snapshot file. First, we create the snapshot: +//! +//! ```bash +//! ./substrate-try-runtime try-runtime --runtime existing -lruntime=debug create-snapshot --uri ws://localhost:9999 +//! 2022-12-13 10:28:17.516 INFO main try-runtime::cli: snapshot path not provided (-s), using 'node-268@latest.snap' +//! 2022-12-13 10:28:17.516 INFO main remote-ext: since no at is provided, setting it to latest finalized head, 0xe7d0b614dfe89af65b33577aae46a6f958c974bf52f8a5e865a0f4faeb578d22 +//! 2022-12-13 10:28:17.516 INFO main remote-ext: since no prefix is filtered, the data for all pallets will be downloaded +//! 2022-12-13 10:28:17.550 INFO main remote-ext: writing snapshot of 1611464 bytes to "node-268@latest.snap" +//! 2022-12-13 10:28:17.551 INFO main remote-ext: initialized state externalities with storage root 0x925e4e95de4c08474fb7f976c4472fa9b8a1091619cd7820a793bf796ee6d932 and state_version V1 +//! ``` +//! +//! > Note that the snapshot contains the `existing` runtime, which does not have the correct +//! > `try-runtime` feature. In the following commands, we still need to overwrite the runtime. +//! +//! Then, we can use it to have the same command as before, `on-runtime-upgrade` +//! +//! ```bash +//! ./substrate-try-runtime try-runtime \ +//! --runtime runtime-try-runtime.wasm \ +//! -lruntime=debug \ +//! on-runtime-upgrade \ +//! snap -s node-268@latest.snap +//! ``` +//! +//! * Execute the latest finalized block with the given runtime. +//! +//! ```bash +//! ./substrate-try-runtime try-runtime \ +//! --runtime runtime-try-runtime.wasm \ +//! -lruntime=debug \ +//! execute-block live \ +//! --uri ws://localhost:9999 +//! ``` +//! +//! This can still be customized at a given block with `--at`. If you want to use a snapshot, you +//! can still use `--block-ws-uri` to provide a node form which the block data can be fetched. +//! +//! Moreover, this runs the `frame_support::try_runtime::TryState` hooks as well. The hooks to run +//! can be customized with the `--try-state`. For example: +//! +//! ```bash +//! ./substrate-try-runtime try-runtime \ +//! --runtime runtime-try-runtime.wasm \ +//! -lruntime=debug \ +//! execute-block \ +//! --try-state System,Staking \ +//! live \ +//! --uri ws://localhost:9999 \ +//! --pallet System Staking +//! ``` +//! +//! Will only run the `try-state` of the two given pallets. When running `try-state` against +//! some real chain data it can take a long time for the command to execute since it has to +//! query all the key-value pairs. In scenarios like above where we only want to run the +//! `try-state` for some specific pallets, we can use the `--pallet` option to specify from +//! which pallets we want to query the state. This will greatly decrease the execution time. +//! +//! See [`frame_try_runtime::TryStateSelect`] for more information. +//! +//! * Follow our live chain's blocks using `follow-chain`, whilst running the try-state of 3 pallets +//! in a round robin fashion +//! +//! ```bash +//! ./substrate-try-runtime \ +//! try-runtime \ +//! --runtime runtime-try-runtime.wasm \ +//! -lruntime=debug \ +//! follow-chain \ +//! --uri ws://localhost:9999 \ +//! --try-state rr-3 +//! ``` #![cfg(feature = "try-runtime")] From 838f507d401c56a57f208d28403787a2db6e1680 Mon Sep 17 00:00:00 2001 From: Liam Aharon Date: Tue, 8 Aug 2023 17:32:26 +0700 Subject: [PATCH 13/16] use node-cli instead of node-template --- Cargo.lock | 2 +- bin/node-template/node/Cargo.toml | 3 --- bin/node-template/node/src/command.rs | 1 - bin/node-template/node/src/lib.rs | 6 ------ test-utils/cli/Cargo.toml | 2 +- test-utils/cli/src/lib.rs | 4 ++-- 6 files changed, 4 insertions(+), 14 deletions(-) delete mode 100644 bin/node-template/node/src/lib.rs diff --git a/Cargo.lock b/Cargo.lock index 1396c1b033567..c9ef6e5ad4fd6 100644 --- a/Cargo.lock +++ b/Cargo.lock @@ -11452,8 +11452,8 @@ dependencies = [ "assert_cmd", "futures", "nix 0.26.2", + "node-cli", "node-primitives", - "node-template", "regex", "sc-cli", "sc-service", diff --git a/bin/node-template/node/Cargo.toml b/bin/node-template/node/Cargo.toml index c4e7cf37c3e49..b05fed96bc8a2 100644 --- a/bin/node-template/node/Cargo.toml +++ b/bin/node-template/node/Cargo.toml @@ -13,9 +13,6 @@ build = "build.rs" [package.metadata.docs.rs] targets = ["x86_64-unknown-linux-gnu"] -[lib] -name = "node_template" - [[bin]] name = "node-template" diff --git a/bin/node-template/node/src/command.rs b/bin/node-template/node/src/command.rs index 40f821ac6dc33..8fc697b5f9c14 100644 --- a/bin/node-template/node/src/command.rs +++ b/bin/node-template/node/src/command.rs @@ -49,7 +49,6 @@ impl SubstrateCli for Cli { } /// Parse and run command line arguments -#[allow(dead_code)] pub fn run() -> sc_cli::Result<()> { let cli = Cli::from_args(); diff --git a/bin/node-template/node/src/lib.rs b/bin/node-template/node/src/lib.rs deleted file mode 100644 index c2a26383bd690..0000000000000 --- a/bin/node-template/node/src/lib.rs +++ /dev/null @@ -1,6 +0,0 @@ -mod benchmarking; -mod chain_spec; -pub mod cli; -mod command; -mod rpc; -pub mod service; diff --git a/test-utils/cli/Cargo.toml b/test-utils/cli/Cargo.toml index 7a0abf524f7be..5e44a4ea5e959 100644 --- a/test-utils/cli/Cargo.toml +++ b/test-utils/cli/Cargo.toml @@ -20,7 +20,7 @@ nix = "0.26.2" regex = "1.7.3" tokio = { version = "1.22.0", features = ["full"] } node-primitives = { path = "../../bin/node/primitives" } -node-template = { path = "../../bin/node-template/node" } +node-cli = { path = "../../bin/node/cli" } sc-cli = { path = "../../client/cli" } sc-service = { path = "../../client/service" } futures = "0.3.28" diff --git a/test-utils/cli/src/lib.rs b/test-utils/cli/src/lib.rs index ee270ab3667b2..99119a44d2e98 100644 --- a/test-utils/cli/src/lib.rs +++ b/test-utils/cli/src/lib.rs @@ -62,9 +62,9 @@ pub fn start_node_inline(args: Vec<&str>) -> Result<(), sc_service::error::Error // Prepend the args with some dummy value because the first arg is skipped. let cli_call = std::iter::once("node-template").chain(args); - let cli = node_template::cli::Cli::from_iter(cli_call); + let cli = node_cli::Cli::from_iter(cli_call); let runner = cli.create_runner(&cli.run).unwrap(); - runner.run_node_until_exit(|config| async move { node_template::service::new_full(config) }) + runner.run_node_until_exit(|config| async move { node_cli::service::new_full(config, cli) }) } /// Starts a new Substrate node in development mode with a temporary chain. From f05764b61e21372bea268eb57ff4469575e4aed7 Mon Sep 17 00:00:00 2001 From: Liam Aharon Date: Tue, 8 Aug 2023 18:02:29 +0700 Subject: [PATCH 14/16] fix feature --- test-utils/cli/Cargo.toml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/test-utils/cli/Cargo.toml b/test-utils/cli/Cargo.toml index 5e44a4ea5e959..29c45a04d18bb 100644 --- a/test-utils/cli/Cargo.toml +++ b/test-utils/cli/Cargo.toml @@ -20,7 +20,7 @@ nix = "0.26.2" regex = "1.7.3" tokio = { version = "1.22.0", features = ["full"] } node-primitives = { path = "../../bin/node/primitives" } -node-cli = { path = "../../bin/node/cli" } +node-cli = { path = "../../bin/node/cli", features = ["try-runtime"] } sc-cli = { path = "../../client/cli" } sc-service = { path = "../../client/service" } futures = "0.3.28" From 0266ef76ef34535f68f2bc77976f0c3bababc444 Mon Sep 17 00:00:00 2001 From: Liam Aharon Date: Tue, 8 Aug 2023 18:13:03 +0700 Subject: [PATCH 15/16] fix feature --- test-utils/cli/Cargo.toml | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/test-utils/cli/Cargo.toml b/test-utils/cli/Cargo.toml index 29c45a04d18bb..314fe7ad568f2 100644 --- a/test-utils/cli/Cargo.toml +++ b/test-utils/cli/Cargo.toml @@ -20,7 +20,10 @@ nix = "0.26.2" regex = "1.7.3" tokio = { version = "1.22.0", features = ["full"] } node-primitives = { path = "../../bin/node/primitives" } -node-cli = { path = "../../bin/node/cli", features = ["try-runtime"] } +node-cli = { path = "../../bin/node/cli" } sc-cli = { path = "../../client/cli" } sc-service = { path = "../../client/service" } futures = "0.3.28" + +[features] +try-runtime = ["node-cli/try-runtime"] From b7363ebbc99bb9be40f9ae1da5263fbcef199fe2 Mon Sep 17 00:00:00 2001 From: Liam Aharon Date: Tue, 8 Aug 2023 18:17:17 +0700 Subject: [PATCH 16/16] fix features --- bin/node/cli/Cargo.toml | 3 ++- utils/frame/try-runtime/cli/Cargo.toml | 3 ++- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/bin/node/cli/Cargo.toml b/bin/node/cli/Cargo.toml index dd8c1c8e77ea9..37f03fbb0dd7e 100644 --- a/bin/node/cli/Cargo.toml +++ b/bin/node/cli/Cargo.toml @@ -184,7 +184,8 @@ try-runtime = [ "pallet-balances/try-runtime", "pallet-im-online/try-runtime", "pallet-timestamp/try-runtime", - "sp-runtime/try-runtime" + "sp-runtime/try-runtime", + "substrate-cli-test-utils/try-runtime" ] [[bench]] diff --git a/utils/frame/try-runtime/cli/Cargo.toml b/utils/frame/try-runtime/cli/Cargo.toml index 61c2fcc2ecdfe..84b9460d137e0 100644 --- a/utils/frame/try-runtime/cli/Cargo.toml +++ b/utils/frame/try-runtime/cli/Cargo.toml @@ -55,5 +55,6 @@ tokio = "1.27.0" try-runtime = [ "sp-debug-derive/force-debug", "frame-try-runtime/try-runtime", - "sp-runtime/try-runtime" + "sp-runtime/try-runtime", + "substrate-cli-test-utils/try-runtime" ]