Question about Nightly toolchain abolishment

[shunsukew]

After the latest release https://github.com/paritytech/srtool/releases/tag/v0.10.0, srtool build start to fail because we're using nightly only feature inside our code. Is there any reason toolchain was changed to stable, and do we have an option to use nightly instead?

[chevdor]

Using nightly is in general not advised. It was done until recently since we had no other choice.

Now that using stable is possible, srtool does that by default and I would suggest checking out your option to not require nightlies.

If you want to stick to nightlies for now, there are a few options:

• use the previous release of srtool (you will have to specifiy only the version and not let the srtool-actions pick it for you)
• build a nightly version of srtool, there is a single line to uncomment, I can point it out if you want to go this route

I would recommend the first option for now and get rid of the nightlies dependencies asap.

[shunsukew]

I see, thank you for your answering.
In that case, we're going to remove nightly features, but I'd like to pick an option to

use the previous release of srtool (you will have to specifiy only the version and not let the srtool-actions pick it for you)

just for recovering current CI failures we encountered.

Which env variable should I provide to srtool-actions to use former version of srtool?

[chevdor]

By default, the GHA will "guess" what is the latest/canonical container image to use based on:

• The rust version
• the container's version

If you don't specify anything, it will pick paritytech/srtool:<RUSTC_VERSION> which is 1.69.0 currently.

To use an older version (for you that would be 1.66.1), you can use the tag input of the GHA.

It would look like:

name: Srtool build using 1.66.1
on: push

jobs:
  srtool:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        chain: ["your_runtime"]
    steps:
      - uses: actions/checkout@v3
      - name: Srtool build
        id: srtool_build
        uses: chevdor/srtool-actions@v0.7.0
        with:
          chain: ${{ matrix.chain }}
          runtime_dir: <path_of_your_runtime
          tag: 1.66.1                                        ⬅️⬅️⬅️ ADD THAT
      - name: Summary
        run: |
          echo '${{ steps.srtool_build.outputs.json }}' | jq . > ${{ matrix.chain }}-srtool-digest.json
          cat ${{ matrix.chain }}-srtool-digest.json
          echo "Runtime location: ${{ steps.srtool_build.outputs.wasm }}"

[chevdor]

⚠️ Please however make a note that this tag input should be removed as soon as you can make it work on stable, so you and your users keep benefiting from the latest/canocial versions. That makes it also simpler for your users who may want to verify your runtime. As long as you set tag, your users should be using the srtool-cli and force the tag there as well with the undocumented:

SRTOOL_TAG=1.66.1 srtool build -p polkadot-runtime --engine podman
[2023-05-02T08:37:01Z INFO  srtool] Running srtool-cli v0.11.0
[2023-05-02T08:37:01Z DEBUG srtool] Checking what is the latest available tag...
[2023-05-02T08:37:01Z INFO  srtool_lib] using tag from ENV: "1.66.1"
[2023-05-02T08:37:01Z INFO  srtool] Using paritytech/srtool:1.66.1
Found 1.66.1, we will be using paritytech/srtool:1.66.1 for the build
[2023-05-02T08:37:01Z DEBUG srtool] engine: 'podman'
[2023-05-02T08:37:01Z DEBUG srtool] app: ''
[2023-05-02T08:37:01Z DEBUG srtool] json: ''
[2023-05-02T08:37:01Z DEBUG srtool] chain: 'polkadot'
[2023-05-02T08:37:01Z DEBUG srtool] default_runtime_dir: 'runtime/polkadot'
[2023-05-02T08:37:01Z DEBUG srtool] runtime_dir: 'runtime/polkadot'
[2023-05-02T08:37:01Z DEBUG srtool] tmpdir: '/var/folders/9g/zcrsl3n9135455gx1zb2t6pc0000gn/T/cargo'
[2023-05-02T08:37:01Z DEBUG srtool] digest: ''
...

[shunsukew]

Sure, thank you for informing.
We almost abolish unstable feature by AstarNetwork/astar-frame#150, basically, it was for just testing.

[Dinonard]

@chevdor may I ask if this is now possible due to some very recent change in polkadot runtime code?

Since we're still getting error in build but now it's due to polkadot-runtime:

error: failed to run custom build command for `shibuya-runtime v5.4.0 (/build/runtime/shibuya)`

Caused by:
  process didn't exit successfully: `/build/runtime/shibuya/target/srtool/release/build/shibuya-runtime-ba4db78d5abec7eb/build-script-build` (exit status: 1)
  --- stderr
  Rust nightly not installed, please install it!
warning: build failed, waiting for other jobs to finish...
error: failed to run custom build command for `polkadot-runtime v0.9.39-1 (https://github.com/paritytech/polkadot?branch=release-v0.9.39#c22e1c41)`

Caused by:
  process didn't exit successfully: `/build/runtime/shibuya/target/srtool/release/build/polkadot-runtime-b2e74745d0fbd966/build-script-build` (exit status: 1)
  --- stderr
  Rust nightly not installed, please install it!

[chevdor]

There were changes for a while already to prepare for this in Substrate.
It was made first possible with Rustc 1.69.0

You seem to be on polkadot v0.9.39-1 which is not very old (21.03) )but we had a few releases since.

We are working now on Polkadot v0.9.42 and it does build fine using srtool 1.69.0

[chevdor]

Closing this issue now, feel free to reopen or ping me if you are stuck

[adamdossa]

Just adding a comment with a work-around that worked for us - agree that ideally stable would be better, but in our case not easily achievable right now.

By creating & copying a rust-toolchain.toml file into the runtime-dir you can force srtool to use a different version of Rust when compiling - e.g.

cp rust-toolchain.toml pallets/runtime/testnet/
SRTOOL_TAG="1.74.0" srtool build --package node-runtime-testnet --runtime-dir ./pallets/runtime/testnet/