paritytech
Consider adding rust-toolchain.toml to the repo
I understand that you use nightly compiler (which version?) for formatting purposes and stable (which version?) for compilation.
When contributing it is somewhat painful to see huge number of warnings caused by project using different (older) version of the compiler.
rust-toolchain.toml will fix at least compilation warnings by ensuring everyone is using exactly the same version without digging into your GitLab pipelines trying to figure out what you happen to use for linting (today it happens to be 1.77.0).
Yeah, when we switched to GHA we can do this switch. Basically the docker image could have the Rust version pre-installed, but the actual version is determined by the rust-toolchain.toml. This way we can bump the Rust version easily and the docker image could be updated later (to reduce CI time).
It is still possible to use +nightly-whatever for formatting purposes, it just defines the default
Just fyi, rust version can be found in the CI image name here
For example, currently the image is docker.io/paritytech/ci-unified:bullseye-1.77.0-2024-04-10-v202407161507, where 1.77 is stable version and 2024-04-10 is nightly version
Hello folks, I'd like some advice on what would be needed in the rust-toolchain.toml file. I've made a basic example here in my PR, which will be used by the getting-started script, and I'm not familiar enough with the entire project's requirements.
I suggest using PRR in the release pipeline if transitioning to GHA. PRR is specifically designed for releasing runtimes based on the Polkadot SDK and provides robust support for rust-toolchain.toml, unlike srtool. This is one of he reasons that I chose to abandon srtool and develop PRR instead.
- https://github.com/chevdor/srtool-actions/pull/22
- https://github.com/w3f/Grants-Program/blob/master/applications/polkadot-runtime-releaser.md
- https://github.com/hack-ink/polkadot-runtime-releaser
- https://github.com/hack-ink/polkadot-runtime-releaser-workshop
