srtool
Describes the Docker container and command-line interface for building the Substrate WebAssembly runtime.
The core component of the Substrate runtime toolbox (srtool) is a Docker container that enables you to build the Substrate WebAssembly runtime in a deterministic way. By using this tool, you can ensure that the same source code consistently reproduces an identical WebAssembly blob. You can also use the tool to inspect and audit the runtime for any Substrate-based chain and to integrate building the WebAssembly runtime into your CI/CD pipeline.
Working with the Docker container
Because srtool is a Docker container, you must have Docker available in your build environment to use it. However, you don't need to know anything about using Docker to build a chain using srtool because you can use the srtool-cli command-line interface to work with Docker images.
The srtiool-cli package is a command-line utility written in Rust that installs an executable program called srtool on your computer. This program simplifies your interactions with the srtool Docker container. Over time, the tooling around the srtool Docker image has expanded to include the following tools and helper programs:
srtool-cli provides a command-line interface to pull the
srtoolDocker image, get information about the image and tooling used to interact with it, and build the runtime using thesrtoolDocker container.subwasm provides command-line options for working with the metadata and WebAssembly runtime built using
srtool. Thesubwasmprogram is also used internally to perform tasks in thesrtoolimage.srtool-actions provides Github actions to integrate builds produced using the
srtoolimage with your GitHub CI/CD pipelines.srtool-app provides a simple graphical user interface for building the runtime using the
srtoolDocker image.
Installing srtool-cli
The srtool command-line interface enables you to build the WebAssembly runtime using the srtool Docker image. You can install the srtool command-line interface by running the following command:
cargo install --git https://github.com/chevdor/srtool-cliBasic command usage
The basic syntax for running srtool commands is:
srtool [options] [subcommand]Options
You can use the following command-line options with the srtool command.
-h, --help
Displays usage information.
i, --image <image>
Specifies an alternative image. Be sure to specify an image that is compatible with the default paritytech/srtool image. You should note that specifying a different image might not produce the same deterministic result that the paritytech/srtool image produces.
-n, --no-cache
Specifies that you don't want to use the tag value from the local cache.
-V, --version
Displays version information.
Subcommands
You can use the following subcommands with the srtool command.
build
Starts a new srtool container to build your runtime.
help
Displays usage information for srtool or for a specified subcommand.
info
Displays information about the srtool container and your repository.
pull
Pulls the srtool image without running anything else.
version
Displays version information for the srtool container. Use --version if you want version information for the srtool-cli executable.
Examples
To get version information for the srtool Docker image, run the following command:
The command displays output similar to the following:
To get version information for the srtool-cli executable, run the following command:
The command displays output similar to the following:
srtool build
Use the srtool build command to start a new srtool container to build the runtime for the package you specify. By default, the srtool build command assumes that the Cargo.toml file for the runtime is located in a runtime subdirectory with the name of the chain. For example, the srtool build command use the following locations by default:
runtime/kusama
runtime/polkadot
runtime/rococo
runtime/westend
If the Cargo.toml file for your runtime is in a different location, you can specify the path as a command-line option.
Basic usage
The basic syntax for running the srtool build command is:
Arguments
By default, the srtool build runs in the current working directory. If your project isn't located in the current working directory, you can specify the path to the project location.
project-path
Specifies the path to the blockchain project you are building the runtime for.
Options
You can use the following command-line options with the srtool build command.
-a, --app
Enables a mix of standard output and JSON output during the build. This option is recommended for CI. The JSON output is provided as a single line at the end of the build.
--build-opts <BUILD_OPTS>
Enables you to pass custom options directly to the cargo build process. If you specify this command-line option, be aware that none of the automatic options for building Kusama or Polkadot are passed to the build process. You must explicitly set the build options you need when you use the --build-opts command-line option. In general, this option rarely required. This option is equivalent to setting the BUILD_OPTS environment variable.
--default-features <default-features>
Enables you to change the list of default features for the runtime without disabling automatic feature detection. This option is equivalent to setting the DEFAULT_FEATURES environment variable. This command-line option has no effect if you set BUILD_OPTS.
-h, --help
Displays usage information.
i, --image <image>
Specifies an alternative image. Be sure to specify an image that is compatible with the default paritytech/srtool image. You should note that specifying a different image might not produce the same deterministic result that the paritytech/srtool image produces.
-j, --json
Enables JSON output.
--no-cache
Disables all caching. If you specify this option, the srtool image won't access the Cargo home cache for build dependencies. In general, this option is rarely used because there are no known issues with using the cache.
-p, --package <package>
Specifies the name of the runtime package you want to build. The name you specify should be the same as the name defined in the Cargo.toml file for the runtime,for example, kusama-runtime, polkadot-runtime, and so on. This option is equivalent to setting the PACKAGE environment variable.
--profile <profile>
Specifies the profile to use for building the runtime, The default profile to build a runtime is always release. You can override the default with this command-line option. This option is equivalent to setting the PROFILE environment variable.
-r, --runtime-dir <runtime>
Specifies the location of the Cargo.toml file for the runtime. If your runtime is not in the standard location, you can use this command-line option to specify the correct location. This option is equivalent to setting the RUNTIME_DIR environment variable.
-V, --version
Displays version information.
Examples
To build the Westend runtime from the cumulus repository where the path to the Cargo.toml for the runtime is parachains/runtimes/assets/asset-hub-westend, you would run the following command:
The first time you run the srtool build command it takes some time to complete. As the runtime compiles, messages about its progress are displayed as standard output. Because this example uses the --app command-line option, JSON output is displayed in a single line at the end of the build similar to the following truncated output:
srtool help
Use the srtool help command to display usage message for srtool or for a specified subcommand.
Basic usage
Examples
To display usage information for the build subcommand, run the following command:
srtool info
Use the srtool info command to display information about the srtool container and your repository. By default, the srtool info command assumes that the Cargo.toml file for the runtime is located in a runtime subdirectory with the name of the chain. For example, the srtool info command use the following locations by default:
runtime/kusama
runtime/polkadot
runtime/rococo
runtime/westend
If the Cargo.toml file for your runtime is in a different location, you can specify the path as a command-line option.
Basic usage
The basic syntax for running the srtool info command is:
Arguments
By default, the srtool info runs in the current working directory. If your project isn't located in the current working directory, you can specify the path to the project location.
project-path
Specifies the path to the blockchain project if the project isn't located in the current working directory.
Options
You can use the following command-line options with the srtool info command.
-h, --help
Displays usage information.
i, --image <image>
Specifies an alternative image. Be sure to specify an image that is compatible with the default paritytech/srtool image. You should note that specifying a different image might not produce the same deterministic result that the paritytech/srtool image produces.
-p, --package <package>
Specifies the name of the runtime package you want to build. The name you specify should be the same as the name defined in the Cargo.toml file for the runtime,for example, kusama-runtime, polkadot-runtime, and so on. This option is equivalent to setting the PACKAGE environment variable.
-r, --runtime-dir <runtime>
Specifies the location of the Cargo.toml file for the runtime. If your runtime is not in the standard location, you can use this command-line option to specify the correct location. This option is equivalent to setting the RUNTIME_DIR environment variable.
-V, --version
Displays version information.
Examples
To display information about the srtool container and the local node-template repository, you might run a command similar to the following:
This command displays output similar to the following:
srtool pull
Use the srtool pull command to check for and download the latest version of the srtool Docker image.
Basic usage
The basic syntax for running the srtool pull command is:
Options
You can use the following command-line options with the srtool pull command.
-h, --help
Displays usage information.
i, --image <image>
Specifies an alternative image. Be sure to specify an image that is compatible with the default paritytech/srtool image. You should note that specifying a different image might not produce the same deterministic result that the paritytech/srtool image produces.
-V, --version
Displays version information.
Examples
To check for a new version of the srtool container and Docker image, you might run a command similar to the following:
This command checks the Docker Hub for the latest version of the paritytech/srtool image and begins downloading and extracting the software. For example
When all tasks are complete, the command displays output similar to the following:
If you already have the latest version installed locally, the command displays output similar to the following:
srtool version
Use the srtool version command display version information for the srtool container. Use --version if you want the version of the srtool-cli executable.
Basic usage
The basic syntax for running the srtool version command is:
Options
You can use the following command-line options with the srtool version command.
-h, --help
Displays usage information.
i, --image <image>
Specifies an alternative image. Be sure to specify an image that is compatible with the default paritytech/srtool image. You should note that specifying a different image might not produce the same deterministic result that the paritytech/srtool image produces.
-V, --version
Displays version information.
Examples
To display information about the srtool container, run the following command:
The command displays output similar to the following:
To display version information for the srtool command-line interface instead of the container, you can run the following command:
The command displays output similar to the following:
Last updated