Closed PierreBesson closed 1 year ago
I am afraid not. This information is not in the runtime unless we decide to add new metadata to it.
It would be possible to write a CLI/script that analyses the code but this would be out of the scope of subwasm
.
I can keep this issue open to track this idea down but don't expect to see this showing up in subwasm
itself.
@ggwpez do you know if the list of migrations could be included in the runtime metadata ? If no then we can close this issue. Providing this feature by analysing the code might be a bad idea as outside of metadatas runtime code doesn't seem to be standardized.
In general, we can add additional sections with whatever data we want in the wasm blob.
I am not sure we really want to add this data though and it does not bring much more than what we can see in the code.
For a rntime version 1000
for instance, you would see that it contains the last 10 migrations:
I have already ideas where adding a few information such as the rust compiler used, etc... used to build the runtime would be super helpful for deterministic checks but I don't think adding migration documenation would be very useful.
We recently added a check in https://github.com/paritytech/substrate/pull/13417 and it reported a lot of missing migrations https://github.com/paritytech/polkadot/issues/7187.
It runs in the CI or locally (in try-runtime
). I would argue that this is a better check, since we empirically verify all pallet versions after the migrations ran. So if there is one missing, it will fail. This does not need metadata or anything, it is just a test basically.
Even with metadata, it could be that the migrations have a wrong name or are faulty, and metadata does not know, but the test would fail.
Otherwise, i guess only parsing the code would work. But is a pain in the ass to implement and breaks easily :laughing:
Thank you for this very interesting discussion. In view of those improvements in Substrate. It doesn't seem too important to have this feature anymore.
I did run the experiment mainly to see how long that can work :) I published:
submig-lib
: where the job is donesubmig
: a simple cli around ittldr:
cargo install submig
submig list /your/path/to/polkadot
output:
Checking migrations in repo: /projects/polkadot
/projects/polkadot/runtime/westend/src/lib.rs:
- V0940
- V0941
- V0942
- Unreleased
/projects/polkadot/runtime/polkadot/src/lib.rs:
- V0940
- V0941
- V0942
- Unreleased
/projects/polkadot/runtime/kusama/src/lib.rs:
- V0940
- V0941
- V0942
- Unreleased
/projects/polkadot/runtime/rococo/src/lib.rs:
- V0940
- V0941
- V0942
- Unreleased
You can also filter to get a single runtime. See readme. More at https://github.com/chevdor/submig
As mentioned in the readme and pointed out by @ggwpez, I would NOT rely on that solution too much as it may collapse when the code structure changes.
Wow @chevdor you did it again. You created yet another CLI !
Lol nice. Lets see how long it works :rofl:
Recently, polkadot runtimes started to include migrations of past releases as well (eg. https://github.com/paritytech/polkadot/pull/7168).
Would it be possible to list to those migrations with subwasm ?