Prevent deploys of apps that Spin can't run

[vdice]

This plugin already performs a few checks on apps before deploying, like ensuring the app has known/supported triggers.

Another scenario has come up recently with the upcoming Spin 3.0 release dropping support for modules built with wasi-sdk < 19. A few other breaking changes in 3.0 are mentioned in fermyon/spin#2815.

This issue is to ensure apps incompatible with Fermyon Cloud are caught at deploy time, returning an appropriate error to the user, rather than allowing them to be deployed but failing to run.

[vdice]

For comparison/code re-use, spin up behavior in Spin 3.0:

application-wide base configuration (other than "/")

issue: fermyon/spin#2583

spin.toml snippet:

[application.trigger.http]
base = "/foo"

$ spin up
Error: This application is using the deprecated trigger 'base' field. The base must be prepended to each [[trigger.http]]'s 'route'.

unsupported modules

issue: fermyon/spin#2552

$ spin up
Logging component stdio to ".spin/logs/"
Storing default SQLite data to ".spin/sqlite_db.db".
Storing default key-value data to ".spin/sqlite_key_value.db".
Error: failed to resolve dependencies for component "session"

Caused by:
   0: an error occurred when preparing dependencies
   1: This Wasm module appears to have been compiled with wasi-sdk version <19 which contains a critical memory safety bug. For more information, see: https://github.com/fermyon/spin/issues/2552

[vdice]

@itowlson is this something we should prioritize for the forthcoming Spin 3.0 release? Would we get both errors 'for free' if we bump the plugin's Spin revision to a commit from the v3.0 branch? Even if so, I'm expecting there may be some non-trivial Factors-related updates needed?

[itowlson]

At the moment the plugn does not load the Wasm modules, merely ensures they exist. So we wouldn't get validation of things like unsupported modules unless we added that.

We need to continue to accept base because we should be able to deploy Spin 2.x applications. These will run on Cloud because the plugin transforms them to be baseless (if memory serves) - Cloud itself does not support base (again if memory serves).

There is a bit of stuff around target worlds that is relevant: I believe that Cloud does not yet have the Spin 3 world and will not be able to load apps that use wasi-config, wasi-keyvalue, or Postgres v3. My preference would be to deliver this via the planned "target environments" validation in Spin (which the plugin could re-host) rather than building something ad hoc into the plugin. How would you feel about leaving that gap for now?

I'm not sure that Factors comes into it. My understanding is that Factors is part of the platform engineering story and shouldn't have anything to do with application development or deployment. (And the Cloud execution engine is already rebuilt on Factors.) Am I missing something?

[itowlson]

Just found that cloud-plugin chokes on component dependencies, although I think Cloud supports them. I will bump the crates and test.