[ci] build runtime only if runtime files were changed

[alvicsam]

PR adds build-runtime-* jobs which run only if files in $runtime_folder/$runtime_name were changed

close https://github.com/paritytech/ci_cd/issues/584

[bkchr]

We don't need to build. You can just use SKIP_WASM_BUILD=1 cargo check

[chevdor]

What about changes in common, pallet and chain_specs and the crates under root ?

Those are outside the folders you you watching but changes in their should trigger a build of all since they are common deps of the runtimes.

You rules are correct for the positive cases "if folder XYZ changed, we need to rebuild runtime XYZ", but if you remove runtime builds from other cases, we will miss some builds when some shared code changes.

[alvicsam]

@chevdor I adjusted paths so if there are changes in common, pallet and chain_specs then all build-runtime-* jobs will be triggered. Not sure about crates under root. Do you mean all that are mentioned in Cargo.toml?

[bkchr]

You rules are correct for the positive cases "if folder XYZ changed, we need to rebuild runtime XYZ", but if you remove runtime builds from other cases, we will miss some builds when some shared code changes.

If you go this route, it could happen that the build is failing when you update Substrate/Polkadot.

[chevdor]

I think we need to include the root folder as well.

You will see 2 types of changes:

• those allowing to rebuild only one or a set of runtimes
• those requiring rebuilding all runtimes (such as common, pallet, root, polkadot/substrate)

Regarding Polkadot/Substrate, we could assume a rebuild is required if the Cargo.lock introduced changes related to Polkadot/Substrate.

[alvicsam]

In this case there is not much sense to distinguish changes between runtime/not runtime. We should run all build-runtime-* checks almost on every commit.

[bkchr]

In this case there is not much sense to distinguish changes between runtime/not runtime. We should run all build-runtime-* checks almost on every commit.

Yeah, sounds the most sensible.

[chevdor]

There are 2 reasons for the runtime build improvements:

• ensure that whatever change landing in master does not break the build of the runtimes
• start thinking about the scenario where we have a big number of runtimes and want to avoid building them ALL all the time

For the first one, building on every commit is the safest option. It was done in the past like that with srtool, we should however prefer an option with caching enabled as running srtool on every commit was very CI consuming. This is why I changed to a single weekly srtool build.

We could however exclude a few patterns to avoid rebuilding all runtimes when the doc, CI scripts, etc.. are changed.

Regarding the second point, we may defer that to another PR but I thought you were trying to move toward some improvements about that as well.

If caching works well, we may not care much about rebuilding all the runtimes everytime though.