Add check runtimes GH Workflow

[chevdor]

This PR introduces:

• a new script
• a new GH Workflow
• runtime reference spec files for rococo and westend

It brings a mechanism to check that part(s) of the runtimes' metadata that should not change over time, actually did not change over time.

Ideally, the GHW should trigger when a release is edited but GH seem to have an issue that prevents the trigger from working. This is why the check has been implemented as workflow_dispatch for a start.

The workflow_dispatch requires a release_id that can be found using:

curl -s -H "Authorization: Bearer ${GITHUB_TOKEN}" \
   https://api.github.com/repos/paritytech/polkadot-sdk/releases | \
   jq '.[] | { name: .name, id: .id }'

as documented in the workflow.

A sample run can be seen here.

[ggwpez]

Could we go by pallet name?

[chevdor]

In this first version, I kept things simple and I am not interpreting the specs. This is why they must match 100% the format of the actuall metadata.

That could be improvement in the future but I would rather get started simple to have this check in place asap.

The benefit of the current option as well is that we can pretty much use the current metadata as spec, that would be may too strict but it works as a starting point.

[ggwpez]

Does it detect typos in the constant names?

[chevdor]

If the spec contains:

 "2": {
        "constants": {
          "foo": { ... }

and the metadata :

 "2": {
        "constants": {
          "foobar": { ... }

It will not detect a typo but it will not find foo and fail.

[ggwpez]

Maybe we should put this into the pipeline-scripts or releng-scripts repo, since it will be useful in the runtimes repo as well.

[chevdor]

Yes indeed, I would create a followup PR for the fellowship runtimes.
I think having this script in the polkadot-sdk repo does also make sense since downstream repos will already likely depend on the polkadot-sdk repo.

[chevdor]

Added comments

[chevdor]

In this first version, I kept things simple and I am not interpreting the specs. This is why they must match 100% the format of the actuall metadata.

That could be improvement in the future but I would rather get started simple to have this check in place asap.

The benefit of the current option as well is that we can pretty much use the current metadata as spec, that would be may too strict but it works as a starting point.

[chevdor]

If the spec contains:

 "2": {
        "constants": {
          "foo": { ... }

and the metadata :

 "2": {
        "constants": {
          "foobar": { ... }

It will not detect a typo but it will not find foo and fail.

[chevdor]

Yes indeed, I would create a followup PR for the fellowship runtimes.
I think having this script in the polkadot-sdk repo does also make sense since downstream repos will already likely depend on the polkadot-sdk repo.