chore: update subwasm dependency to 0.19

ntn-x2 commented 1 year ago

Since the new subwasm version includes a feature we need, this PR bumps the subwasm dependency to the newly released version 0.19 which includes this feature.

ntn-x2 commented 1 year ago

Sorry, I probably made a bigger deal than it was 😄 I reverted to only change the subwasm value. All good now.

ntn-x2 commented 1 year ago

@chevdor I guess it can be merged now 😁

ntn-x2 commented 1 year ago

When can I expect a Docker image with this fix to be released?

chevdor commented 1 year ago

When the next release is finalized :) I really can't give a date since I am waiting for features to land and I also don't have a date for those.

ntn-x2 commented 1 year ago

@chevdor we kind of need this feature in rather sooner than later, and would like to avoid building our own image. There is no breaking change since subwasm is retro-compatible. Would it make sense to have a patch release with this change in?

chevdor commented 1 year ago

One of the goal of srtool is to remain "stable" over time so I refrain from making new version unless there are excellent reasons to do so:

known vulnerability patched in newer version
relay chains runtimes no longer building on older compilers
compiler getting too old (usually >~ 6 months)
compiler bringing a neat new feature we want asap

While building your own image would be an option, I would recommend against it as users could no longer use the canonical version of srtool anymore.

Instead, I can think of 2 options and the later is IMO the best:

Swap `subwasm` using volume mapping

use the existing srtool
install the new subwasm version locally
"swap" the subwasm bin in the docker container using volume mapping

That would not break determinism and you could use the new features of subwasm already.

RISK: You may need to "swap" a few other scripts as well.

Local`subwasm` run

You could even run the local (newer) subwasm after the srtool build. subwasm is integrated inside srtool as a helper and it makes it convenient to have it there but you don't have to use the subwasm version included in the srtool image so you could let srtool do its things using the older subwasm version, ignore the subwasm outputs, run the newer subwasm yourself and use those results. The execution time penalty will be negligible considering the time it takes to run srtool.

ntn-x2 commented 1 year ago

@chevdor I see there are few images with a tag structure of, for instance, 1.66.0-0.9.24 and so on. These look like dev tags, but for us, for the time being, it would be totally ok. This is also not possible?

paritytech / srtool