Update CI Rust checks

[eagr]

helps #19

summary

• use dtolnay/rust-toolchain instead
• use nightly for both fmt and clippy, for the latest features
• clippy -- --deny warnings (let me know if this isn’t what you want)
• use matrix for testing (easier to add more targets)

I combined fmt and clippy into one job so that we don’t have to repeat the checkout-install ceremony. Also coz by definition linting does address stylistic errors. :)) But if you don’t like it, I could split them, no problem.

Curious, is there a reason why we’re using ubuntu-20.04 instead of ubuntu-latest?

[liamaharon]

Curious, is there a reason why we’re using ubuntu-20.04 instead of ubuntu-latest?

No reason in particular. We could probably bump to 22.04, but I don't think it's so consequential.

[eagr]

Interesting, normally dev build should be faster, but not the other way around. Any idea why?

[liamaharon]

Interesting, normally dev build should be faster, but not the other way around. Any idea why?

Weird GH Action env 🤷

[liamaharon]

Thanks for this!

[eagr]

Just a wild guess. Maybe, unlike the release build, somehow the dev build artifacts are not properly cached in the environment, so it needs to build dependencies every time.

Now that the cache is in place, future test runs should hopefully see some improvements. But I made linting slower, probably a caching problem. I'll fix that.

[eagr]

try-runtime-cli/core/tests/create_snapshot.rs

Line 73 in fd0ec95

let block_hash = common::block_hash(block_number, &ws_url).await.unwrap();

Thread 'create_snapshot_works' panicked at 'called `Result::unwrap()` on an `Err` value: "`WsClientBuilder` failed to build:
Transport(Error when opening the TCP socket: Connection refused (os error 111))"',
/home/runner/.cargo/git/checkouts/polkadot-sdk-cff69157b985ed76/cfb2925/substrate/test-utils/cli/src/lib.rs:263

The code panicks with dev build in CI, the workflow stops right there, before the tooling has the chance to save the artifacts. That's why the build is always slow. Any idea why it would break on dev build (but not on release)?

[liamaharon]

Any idea why it would break on dev build (but not on release)?

Maybe the debug build is too slow on the runner and it can't properly establish a connection.

The runner is very computationally limited and the test pretty heavy, it spins up an entire node.

[eagr]

Updates:

• Pin nightly to make caching more effective
• Tag lint cache to differentiate it (it's not entirely necessary, just to be safe)
• Remove the cleansing step as it's no longer needed now, which could save another 150s. We'd have a 10G margin (after the test), should be safe, right? But in case I'm wrong, it's easy to add it back.

The jobs now complete in ~16min, seems reasonable.

[eagr]

I got an idea for the test. Instead of sleeping for 90s, how about we try connecting every X seconds, but with a deadline. May make the tests less fragile. Also may be able to save us a bit more time. Do you think it makes sense?

[simonsso]

The runner is very computationally limited and the test pretty heavy, it spins up an entire node.

@liamaharon do you have access to some faster build nodes like the ubuntu-latest-4-cores or ubuntu-latest-8-cores in this project?

[liamaharon]

I got an idea for the test. Instead of sleeping for 90s, how about we try connecting every X seconds, but with a deadline. May make the tests less fragile. Also may be able to save us a bit more time. Do you think it makes sense?

This has been on my radar for a while I just haven't gotten around to it. Would be great to see this improvement in a new PR :)

@liamaharon do you have access to some faster build nodes like the ubuntu-latest-4-cores or ubuntu-latest-8-cores in this project?

We could probably, but I'm quite happy with the numbers in this PR I don't think it is necessary.