chore: update subwasm dependency to 0.19

[ntn-x2]

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]

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

[ntn-x2]

@chevdor I guess it can be merged now 😁

[ntn-x2]

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

[chevdor]

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]

@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]

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.

Localsubwasm 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]

@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?