add support for wasi:http/incoming-handler@0.2.0-rc-2023-11-10
#2166
Conversation
This builds upon Alex's excellent work in spinframework#2108, adding the ability to run guests which target the `0.2.0-rc-2023-11-10` version of `wasi-http`. I've added a test which uses `wit-bindgen` and `wit-component` directly to ensure it uses the correct snapshot for everything `wasi-http`, `wasi-cli`, etc. Note that we're not yet updating any SDKs to use the new snapshot, since we still want people to be able to use the new SDK to target Spin 2.0. Signed-off-by: Joel Dice <joel.dice@fermyon.com>
…ponent Previously, I tried to be clever and overwrite the module with the component, but that led to a filesystem-level race condition and was just generally fragile. Signed-off-by: Joel Dice <joel.dice@fermyon.com>
I try to avoid Docker when testing and debugging since it adds overhead and (IMO) not a lot of value for simple tests like this. Can (a subset of) the runtime tests be run without it? |
|
@dicej we only run inside of Docker in CI currently because that's where the e2e tests run - the runtime tests have no dependency on Docker and can be run outside of a Docker container (which I do locally). Avoiding one-off tests like this is the exact goal of the runtime tests, so if you're feeling resistance towards adding one, it makes me want to have a conversation again about how we unify testing. |
|
I didn't realize Docker was optional -- glad to hear it is. Maybe we can pair up and you can walk me through converting this to a runtime test? |
This builds upon Alex's excellent work in
#2108, adding the ability to run guests which target the
0.2.0-rc-2023-11-10version ofwasi-http.I've added a test which uses
wit-bindgenandwit-componentdirectly to ensure it uses the correct snapshot for everything:wasi-http,wasi-cli, etc.Note that we're not yet updating any SDKs to use the new snapshot, since we still want people to be able to use the new SDK to target Spin 2.0.