3

I'm integrating srtool into my CI build. As a result of the build, I aim to obtain the client and the runtime. I can compile the runtime with srtool action and run cargo build to get the client. But with this approach, CI has to build the runtime twice which is time-consuming.

The questions:

  1. Is it possible to avoid duplicating work while obtaining both the client and the runtime as build results?
  2. If it's challenging to avoid double work, is it acceptable for the node client to be compiled with a different build from the runtime?

Side notes:

  1. I didn't find any signs in srtool documentation that it is possible to compile node client with it.
  2. It's not possible to compile the node client separately from the runtime as the client depends on the runtime.

1 Answer 1

2

If you want to skip the WebAssembly build process for your client, you can use the SKIP_WASM_BUILD option and assemble it with the srtool artifacts later.

However, I believe this may not be a wise decision.


Since GitHub actions have the capability to run simultaneously, why not start these two jobs together?

I don't think CI has to build the runtime twice which is time-consuming.

1
  • I've made some research on how Srtool works and it appears that it's cargo build --locked in a docker container. As the build in CI was already containerized, I decided to simply add --locked to have the same deterministic build as Srtool gives. Aug 7 at 13:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.