srtool
It especially helps with building and verifying WASM Runtime Blobs. You may read more about it here.
The Docker image is chevdor/srtool. You can find it at https://hub.docker.com/r/chevdor/srtool.
1. Install
1.1. Pull image
docker pull chevdor/srtool:<version> # (1)
-
where
<version>is the rustc version you want to use.
…or just skip that step, the right image will be fetched at first run.
1.2. Using an alias
Creating an alias helps hiding the docker complexity behind one simple command. We will see more powerful options but this one is simple enough.
export RUSTC_VERSION=nightly-2020-03-12; export PACKAGE=kusama-runtime; alias srtool='docker run --rm -it -e PACKAGE=$PACKAGE -v $PWD:/build -v /tmp/cargo:/cargo-home chevdor/srtool:$RUSTC_VERSION'
|
Note
|
Note that defining the alias as done above will hardcode the runtime. Using kusama-runtime as show above means you will always check the kusama runtime. If you need more, check the next chapter.
|
|
Note
|
If you want to check what your alias is, use type srtool
|
The command to invoke a build will then be srtool build.
1.3. Power users
If you want flexibility, using a function is slightly more complex but more flexible.
If you already defined an alias (you can check with type srtool), you should first unset it with unlias srtool.
|
Note
|
You cannot use both an alias and a function but you could make a function called fsrtool for instance for the function… |
1.3.1. Hardcoded compiler version
This option should be enough most of the time.
function srtool() { docker run --rm -it -e PACKAGE=$1 -v $PWD:/build -v /tmp/cargo:/cargo-home chevdor/srtool:nightly-2020-03-12 $2; }
The commands to use srtool are then:
srtool kusama-runtime build
|
Note
|
The <kusama-runtime> keyword above specifies we will check the kusama runtime. If your runtime is called xyz-runtime, swap accordingly. |
1.3.2. Parametric compiler version
Using this version is more powerful if you know what you are doing but also requires more typing.
function srtool() { docker run --rm -it -e PACKAGE=$1 -v $PWD:/build -v /tmp/cargo:/cargo-home chevdor/srtool:$2 $3; }
The command to invoke a build will then be srtool <package> <rust_version> build. For instance:
srtool my-super-runtime nightly-2020-03-12 build
srtool polkadot-runtime nightly-2019-12-05 build
WRNING: The second example is only there to illustrate how it works. If you try it today, it will likely not work as I did not build a container for this version yet.
You likely want to make this persistent with:
echo "export RUSTC_VERSION=nightly-2020-03-12; export PACKAGE=polkadot-runtime; alias srtool='docker run --rm -it -e PACKAGE=$PACKAGE -v $PWD:/build -v /tmp/cargo:/cargo-home chevdor/srtool:$RUSTC_VERSION'" >> ~/.bash_profile && source ~/.bash_profile
If you wish to see more (it takes a little longer), you may set the VERBOSE ENV variable:
export RUSTC_VERSION=nightly-2020-03-12; export PACKAGE=polkadot-runtime; alias srtool='docker run --rm -it -e PACKAGE=$PACKAGE -e VERBOSE=1 -v $PWD:/build -v /tmp/cargo:/cargo-home chevdor/srtool:$RUSTC_VERSION'
|
Note
|
The part -v /tmp/cargo:/cargo-home exposes the docker container’s cargo cache on your local machine. This helps making subsequent builds faster.
|
2. Use
Now that you defined the srtool alias, you can use it as shown below:
srtool help
srtool build
Invoking srtool build with:
srtool build
Will output something that looks like this:
🧰 Substrate Runtime Toolbox 🧰
🏗 Building polkadot-runtime as release
⏳ That can take a little while, be patient... Subsequent builds will be faster.
Finished release [optimized] target(s) in 37.43s
real 0m37.931s
user 0m1.560s
sys 0m3.220s
✨ Your Substrate WASM Runtime is ready! ✨
Summary:
Used rustc nightly-2020-03-12 (4560ea788 2019-11-04)
Wasm : ./srtool/release/wbuild/polkadot-runtime/polkadot_runtime.compact.wasm
Content : 0x0061736d0100000001a4022b60037f7f...3435663020323031392d31322d303429
Size : 1.1M
Proposal : 0x5931690e71e9d3d9f04a43d8c15e45e0968e563858dd87ad6485b2368a286a8f
SHA256 : d5930520676994fc55a29c547f0159ea860cb46edd710a5be35e62565af1ad8b
If you prefer a json output, srtool has you covered:
$ srtool build --json
Will give you such an output:
{
"gen": "srtool",
"rustc": "rustc 1.41.0-nightly (ae1b871cc 2019-12-06)",
"wasm": "./target/srtool/release/wbuild/kusama-runtime/kusama_runtime.compact.wasm",
"size": "1205052",
"pkg": "kusama-runtime",
"prop": "0x5931690e71e9d3d9f04a43d8c15e45e0968e563858dd87ad6485b2368a286a8f",
"sha256": "d93126c814f8366b651e425e34390212a98f8e77a8b73f9e1d2b07fc229a25f1",
"tmsp": "2020-01-14T10:15:28Z"
}
3. Proposal field
What is important in the output of srtool is the Proposal field:
🧰 Substrate Runtime Toolbox 🧰
... Bla bla ...
Proposal : 0x5931690e71e9d3d9f04a43d8c15e45e0968e563858dd87ad6485b2368a286a8f
... more blabla ...
The Proposal field value should should match the value of the proposal you can see in the Polkadot UI.
if you feel fancy, you may also:
srtool bash
and look around the /srtool folder
4. Build the Docker image
While you don’t have to build the image yourself, you still may!
First you may want to double check what rustc versions are available as you will HAVE to build an image for a given version:
rustup check
So say you want to build a builder for rustc nightly-2020-03-12:
RUSTC_VERSION=nightly-2020-03-12 && docker build --build-arg RUSTC_VERSION=$RUSTC_VERSION -t chevdor/srtool:$RUSTC_VERSION .
Wilfried Kopp aka. Chevdor
Building Blockchains & Decentralized Solutions
I build decentralized solutions and tooling to support them. I am developing Smart Contracts and dApps on Ethereum and developing tooling for Substrate (Polkadot & Kusama). I love Rust! I am using Docker extensively and above all I like efficiency. GPG Fingerprint 15AF C574 D3F9 F1C3 CCDD E31E 2DCE C4DC 506E 6475.