Async entry point#78
Conversation
itowlson
force-pushed
the
asyncify
branch
2 times, most recently
from
c392604 to
2381ccf
Compare
|
@itowlson these would be triggers that would likely be executed with Spin 4.0 right? I think breaking changes may make sense |
vdice
left a comment
vdice
left a comment
There was a problem hiding this comment.
a few quick comments on the CI updates before giving the async thoughts a ponder...
| - name: Install pluginify | ||
| shell: bash | ||
| run: spin plugins install --url https://github.com/itowlson/spin-pluginify/releases/download/canary/pluginify.json --yes | ||
| run: spin plugins install pluginify --yes |
There was a problem hiding this comment.
note: you can do away with this separate step and replace it with plugins: pluginify in the previous spin/setup step (https://github.com/spinframework/actions?tab=readme-ov-file#install-spin-cli-and-plugins---spinframeworkactionsspinsetupv1)
| - name: Install pluginify | ||
| shell: bash | ||
| run: spin plugins install --url https://github.com/itowlson/spin-pluginify/releases/download/canary/pluginify.json --yes | ||
| run: spin plugins install pluginify --yes |
| - name: Install pluginify | ||
| shell: bash | ||
| run: spin plugins install --url https://github.com/itowlson/spin-pluginify/releases/download/canary/pluginify.json --yes | ||
| run: spin plugins install pluginify --yes |
There was a problem hiding this comment.
noting this if similar steps are updated in build.yml
Echoing @kate-goldenring's sentiment - SpinKube (really, the containerd-shim-spin project) would update triggers at the same time as updating core Spin runtime/libraries to 4.0 and I'm assuming there will be breaking changes in the latter, so it seems apt to bring in the same for the plugins. |
|
I believe Spin 4's breaking changes are UI only, not runtime. We are not breaking any component compatibility (or if we do, it's a bug). |
itowlson
force-pushed
the
asyncify
branch
2 times, most recently
from
b7aeb12 to
89d22ed
Compare
|
Updated to v4 final @fibonacci1729 |
Signed-off-by: itowlson <ivan.towlson@fermyon.com>
4 participants
Sharing this for discussion purposes across the cron, MQTT, etc. trigger plugins.
The way I've done this would no longer run components with the synchronous entry point, which doesn't worry me too much for the plugin, but I could see it being a problem for SpinKube. We have the technology to make it so it can handle both (https://github.com/spinframework/spin/blob/24d2100d421647238a5f9f495bb3903895824f08/crates/trigger-redis/src/lib.rs#L216) but with the way the code is structured it means either 1. faff or 2. continuing to use types from the vendor-named package in the neutral-named package.
So I'm posting this to get feedback on how we want to tackle these custom triggers. All in on async and to heck with backward compatibility? Or put in more time and keep existing stuff working?
(Unrelated: I don't think I have an AWS account for testing this. If anybody could give me a hand verifying that it works, I'd appreciate it a lot!)It turns out we have an E2E test in CI!