Skip to content

Latest commit

 

History

History
215 lines (132 loc) · 8.45 KB

README_src.adoc

File metadata and controls

215 lines (132 loc) · 8.45 KB
Raw

Substrate Runtime Toolbox: srtool v0.14.0

Table of Contents
srtool docker 128px

1. Intro

srtool is a collection of containerized tools helping with building WASM Runtimes for the Polkadot Network. srtool especially allows building WASM runtimes in a deterministic way, allowing CIs and users, with various machines and OS, to produce a strictly identical WASM runtime.

srtool can run on various Operating Systems supporting Podman or Docker. That includes Linux, MacOS and Windows.

srtool helps building and verifying WASM Runtimes. The Docker image is named paritytech/srtool. You can find the project’s repository at https://hub.docker.com/r/paritytech/srtool.

2. Docker image naming scheme

The Docker images are tagged with both the rustc version used internally as well as the version of the build script.

You may find for instance the following:

  • paritytech/srtool:1.75.0-0.14.0

  • paritytech/srtool:1.75.0

The tags not mentioning the build version always point to the latest one. In the example above, paritytech/srtool:1.75.0 is the same image than paritytech/srtool:1.75.0-0.14.0.

3. Related tools

There are a few other helpers you may want to check out when using srtool:

  • srtool-cli: This Rust executable supersedes the previously recommended alias solution. It brings many benefits and is much easier to use.

  • srtool-app: The basic features of srtool in a simple GUI, available on multiple platforms.

  • srtool-actions: This Github actions makes it much easier to integrate srtool in your CI.

  • …​ and more to come

Frame 1 256

srtool is a tool for chain builders, it is widely used in CI such as Github Actions, it can also be used by anyone who wants to independently check and audit the runtime of a chain or a parachain.

You may also want to have a look at subwasm as it is now part of the tooling included in srtool. subwasm can also be used independently upon building your wasm with srtool.

4. History

The project was initially developed by https://gitlab.com/chevdor. It has now moved to Github under the Parity Technologies organisation to simplify the developement and the integration with other Parity products such as Polkadot and Kusama.

The last version hosted on Gitlab has been built using Rust Stable 1.75.0. It is tagged as v0.14.0 and there is no plan on updating the Gitlab repository further. New versions will be available from this repository only. The functionalities remain the same so you can (and should!) simply swap chevdor/srtool for paritytech/srtool in your workflows. The srtool-actions will remain available as chevdor/srtool-actions@<version> and will be updated to point at the paritytech image.

5. Install

5.1. Install the srtool-cli

Since the srtool-cli exists, there is no reason to be using an alias anymore. Using the cli over the alias brings many advantages and will save you time.

The srtool-cli is a command line utility written in Rust. You can read more about the installation process here.

5.2. Using an alias

Important
 This method is legacy and deprecated. It is recommended to use the srtool-cli utility mentioned above. This information is left here for documentation purposes only — all the functions are now availabe in the srtool-cli.

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=1.75.0; export PACKAGE=kusama-runtime; alias srtool='docker run --rm -it -e PACKAGE=$PACKAGE -v $PWD:/build -v $TMPDIR/cargo:/cargo-home paritytech/srtool:$RUSTC_VERSION'
Note
 Note that defining the alias as done above will hardcode the runtime. Using kusama-runtime as shown 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.

6. Use

Now that you have defined the srtool alias, you can use it as shown below:

See the help
$ srtool help
Build the runtime
$ srtool build
Typical run

Invoking srtool build with

$ srtool build

will output something that looks like this:

    🧰 Substrate Runtime Toolbox - srtool v0.14.0 🧰
              - by Chevdor -
    🏗  Building polkadot-runtime as release using rustc 1.75.0
    ⏳ That can take a little while, be patient... subsequent builds will be faster.
    Since you have to wait a little, you may want to learn more about Substrate runtimes:
    https://docs.substrate.io/learn/architecture/

        Finished release [optimized] target(s) in 37.43s

and finally …​

link:doc/sample-output.txt[role=include]
JSON output

If you prefer a json output, srtool has you covered:

$ srtool build --json

The output will look something like:

link:doc/sample-output.json[role=include]

7. Troubleshooting

7.1. Outdated repo

If you run into issues while running srtool, make sure you’re using a decently recent version of Polkadot/Substrate:

Then run the following commands:

rm -rf target/srtool
cargo clean
cargo update

You can now try running srtool build again.

7.2. srtool tells me the folder is not a cargo project

The error is probably: !!! The folder on your host computer does not look like a Cargo project. Are you really in your repo?`

Run the following command:

alias srtool

And make sure that you see $PWD:/build/ and not /home/your_name/:/build. If you’re running into this issue, your .bash_profile likely contains double quotes (") where you should have used single ones (').

7.3. Other cases

If you still run into any trouble, please open a new issue and describe the error you see and the steps you took.

8. 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 match the value of the proposal you can see in the Polkadot UI.

9. IPFS Hash

Starting with version 0.9.8, the IPFS hash is computed and added to the output. srtool is only computing the hash. It neither publishes the file to IPFS nor connects to IPFS.

Advanced usage

If you’re feeling fancy, you may also run:

srtool bash

and look around the /srtool folder.

10. User Scripts

You can see the list of available scripts in the /scripts folder:

  • help: Show some help.

  • version: Show some version.

  • info: Show available system info before running a build.

  • build: Run the actual build.

  • scan: Scan a repo for runtimes

Note
 The info and version scripts pass any arguments you pass to the script to jq. So you can play with c (compact), -M (monochrome), -C color output. For instance docker run --rm -it -v $PWD:/build chevdor/srtool:1.75.0 info -cM shows a monochrome output on a single line.

11. Build your custom chain / parachain

Building the runtime for your custom chain may not work with the default used for Kusama, Polkadot and Co. You can however help srtool make the right choices using ENV VARs. You will need to make a new alias as shown below.

Here’s how to build the runtime for the substrate-node-template, for instance:

alias mysrtool='docker run --rm -it --name mysrtool -e RUNTIME_DIR=runtime -e BUILD_OPTS=" " -e PACKAGE=$PACKAGE -v $PWD:/build -v /tmp/cargo:/cargo-home chevdor/srtool:$RUSTC_VERSION'
Note
 BUILD_OPTS is set to a space, not an empty string.
Note
 Using srtool-cli makes the above much easier…​

12. Export the runtime

To easily export your runtime, it will be copied in the container into the /out folder. If you mount this docker volume, you will find the wasm on your local filesystem once the run is complete.

docker run ... -v /tmp/out:/out ...