Option to force build before deploy

[itowlson]

Fixes #95.

Happy path:

ivan@hecate:~/testing/hello3$ spin deploy --build
Building component hello3 with `cargo build --target wasm32-wasi --release`
   Compiling hello3 v0.1.0 (/home/ivan/testing/hello3)
    Finished release [optimized] target(s) in 1.19s
Finished building all Spin components
Uploading hello3 version 0.1.0+r73691dd...
Deploying...
Waiting for application to become ready.......... ready
Available Routes:
  hello3: https://hello3-prfvru2v.fermyon.app (wildcard)

Sad path:

ivan@hecate:~/testing/hello3$ spin deploy --build
Building component hello3 with `cargo build --target wasm32-wasi --release`
   Compiling hello3 v0.1.0 (/home/ivan/testing/hello3)
error[E0425]: cannot find function, tuple struct or tuple variant `Sum` in this scope
  --> src/lib.rs:12:15
   |
12 |         .body(Sum("Hello, Mistress Ploppy".into()))?)
   |               ^^^ not found in this scope

For more information about this error, try `rustc --explain E0425`.
error: could not compile `hello3` (lib) due to previous error
Error: Build command for component hello3 failed with status Exited(101)
Error: Build failed: deployment cancelled

I know that's a lot of errors at the end but that's fiddly to fix with the way Rust handles Result::Err exits. It can be addressed but I'm not keen to rework that as part of this PR.

[karthik2804]

We could potentially add a shorter argument "-b"? Just curious and do not have any strong preference or is this match with spin

[itowlson]

spin up currently only supports the long form.

[karthik2804]

Would it make sense to add this as a constant? I mean the string "SPIN_BIN_PATH"

[itowlson]

I tried creating a const but it ended up feeling like noise so I rage-encapsulated it as a "give me the Spin binary path" function instead

[michelleN]

Does the build option conflict with deploy existing bindle? How should one think about these two options?

[itowlson]

Does the deploy existing bindle option still exist? I couldn't see it in the code but yeah there's not much point doing a build of the local app just to deploy an existing remote app (although I think it would be harmless but I'm not sure what deploy existing bindle does).

[itowlson]

Oh I see it existed in main when I wrote this PR but not when I looked at main just now. So I think this conundrum has gone away (thanks Vaughn and Team OCI)

[michelleN]

Not sure. It would be nice to sync on all the bindle related code for 2.0 (added to 2.0 board). For now, does it make sense to add a conflicts_with requirement to the deploy-existing-bindle flag for clarity? Agree on it being harmless though.

[itowlson]

Sorry - I wasn't clear because I was figuring things out as I went! I can't add a conflicts_with on deploy-existing-bindle because deploy-existing-bindle was removed. There is no bindle any more: there is only OCI. And there is no longer a redeploy option. So the problem goes away.

[michelleN]

excellent!