Add `dfx deploy --no-build` to skip the build

[nmattia]

It would be great to have a way to not run the build command specified in .canisters.<canister name>.build in dfx.json when the .canisters.<canister name>.type is custom.

This is particularly useful if one wants to only deploy a canister fetched from somewhere, like for instance from a docker build. There are some workarounds, unfortunately none that is very satisfactory:

• Use an environment variable to skip the build in the build command, e.g. deploy with DFX_NOBUILD=1 dfx deploy ... and read the value of DFX_NOBUILD in the build command and skip the build accordingly. This is a bit hacky and I find it strange for a build script to start with if [[ "${DFX_NOBUILD:-} == "1" ]]; then exit 0; fi; might as well not run the script.
• Use a combination of dfx canister create && dfx canister install. This is a bit problematic because it needs extra logic to know whether or not to first create the canisters, and what install mode to use (install, reinstall, upgrade).

It would be great if dfx could support this out of the box. Another possibility would be to decide whether or not to retrigger a build based on timestamps (a la make/cargo/etc) but this would be very tricky since dfx doesn't know which files are involved in the build.

[nmattia]

Alternatively, we could also have a --wasm my_canister.wasm argument. When specified, the build would be skipped and my_canister.wasm would be used instead. Would be extra nice if my_canister.wasm could also be a URL!

[nmattia]

@sesi200 this was handled in https://github.com/dfinity/sdk/blob/master/CHANGELOG.adoc#feat-install-arbitrary-wasm-into-canisters, correct?

[sesi200]

@nmattia your call if this is handled. The linked change only allows installing a local wasm module, nothing within dfx deploy or remotely fetching wasms is included in that.

[nmattia]

Right, I think having the --wasm arg ported to dfx deploy is what I'm looking for. Would that be a problem?

[sesi200]

Hmm, how would that behave if I have two canisters in my project? Or is it just a problem of dfx canister install not being convenient enough to use?

[nmattia]

I guess it would behave just like --argument right? :)

Yes, dfx canister install is not as convenient to use AFAIR because you need extra logic around it to e.g. create the canister if it doesn't exist. But I agree that having --wasm on multiple canisters is not great!

[adamspofford-dfinity]

@nmattia Would unconditionally using dfx canister create be inconvenient? It does return success if the canister was already created; the only difference between dfx canister create && dfx canister install that I can think of is an extra line of stdout, which shouldn't matter in a shell script.

[nmattia]

Ah, I see!

It does return success if the canister was already created

Great, is that new?

the only difference [...] is an extra line of stdout

Gotcha! I thought I'd have to explicitly deal with the install mode. If you can confirm that's not the case then I'm happy to close the ticket!

[adamspofford-dfinity]

Aha, that's the trap. It doesn't. I wonder whether a fourth mode that can figure out whether it should be install or upgrade would be a better solution than --no-build, though.

[sesi200]

Ugly hack: dfx canister install --mode install || dfx canister install --mode upgrade