You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This discussion is about getting feedback on the Updatecli external autodiscovery plugin feature.
It's still experimental, and we need as much feedback as possible to confidently move it to stable without future breaking changes
Problem
Defining update strategies in YAML is convenient, saves time, and helps teams collaborate. But when update rules grow complex, a small DSL can become limiting. Recently, we explored using WASM to let teams write manifest generators in the language they prefer. The feature is still experimental, and we welcome feedback from teams with complex update scenarios.
Solutions
Plugins can be written in any language that compiles to WebAssembly (WASM). We explored using the Extism framework.
We implemented on the Updatecli side this pull request:
A plugin must export the function _start (WASI). It is expected to receive a JSON object as input and return a JSON object containing the generated Updatecli manifests.
Input
A plugin receives a JSON object with the following fields:
The scmid field is provided by Updatecli, it's up to the plugin maintainer to decide how to use that information, but typically it's used to link resources to a scm configuration specified in the Updatecli manifest.
The actionid field is provided by Updatecli, it's up to the plugin maintainer to decide how to use that information but typically it's used to specify an action title.
The spec field is the plugin parameters detected by Updatecli.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
This discussion is about getting feedback on the Updatecli external autodiscovery plugin feature.
It's still experimental, and we need as much feedback as possible to confidently move it to stable without future breaking changes
Problem
Defining update strategies in YAML is convenient, saves time, and helps teams collaborate. But when update rules grow complex, a small DSL can become limiting. Recently, we explored using WASM to let teams write manifest generators in the language they prefer. The feature is still experimental, and we welcome feedback from teams with complex update scenarios.
Solutions
Plugins can be written in any language that compiles to WebAssembly (WASM). We explored using the Extism framework.
We implemented on the Updatecli side this pull request:
And an example of a custom plugin named demo.
A plugin must export the function
_start(WASI). It is expected to receive a JSON object as input and return a JSON object containing the generated Updatecli manifests.Input
A plugin receives a JSON object with the following fields:
{ "scmid": "default", "actionid": "default", "rootdir"": "current directory" "spec": { "plugin_param1": "", "plugin_param2": "" } }The
scmidfield is provided by Updatecli, it's up to the plugin maintainer to decide how to use that information, but typically it's used to link resources to a scm configuration specified in the Updatecli manifest.The
actionidfield is provided by Updatecli, it's up to the plugin maintainer to decide how to use that information but typically it's used to specify an action title.The
specfield is the plugin parameters detected by Updatecli.Output
A plugin must output a JSON object such as
{ "manifests": [ "Updatecli manifest 1", "Updatecli manifest 2" ] }Where
manifestscontains the list of generated Updatecli manifestsGuidelines:
versionfield in generated manifests to indicate the minimum Updatecli version required.pipelineidin generated manifests (Updatecli overrides it).Improvement
Beta Was this translation helpful? Give feedback.
All reactions