After building a serverless workflow image the next step is to generate the operator-specific manifests for it.
Today this is done using kn-workflow gen-manifesttool and in a separate step. You need to create some pipeline (automation...) that will
locate the serverless resources (.sw.yaml|json, application.props, specs/, schemas/*)
create the sonataflow image with the swf-builder
generate the manifests using kn-workflow
step 3 have a lot of room for mismatch and errors. the kn-workflow tool has a dependency on the sdk-go version of the serverless workflow api, and it must match with artifact the build the images.
Also, every user that needs to create this sort of pipeline need to collect the right version of tool and create that automation themselves. Even with docs and examples there are no effective guardrails against mistakes.
Instead, I suggest that as part of the image creation process, the swf-builder would also produce the manifests and store them
along the rest of the artifacts under the Runtime image:
/deployemtns/quarkus-run.jar -> the app
/deployments/manifests/01-sonataflow-foo.yaml -> manifests
After the image creation the automation can extract the /deployment/manifests/ dir from the image and store the in a config repository for example.
This kind of coupling is welcomed as it removes manual, error-prone steps from users. After all the manifests generation is coupled with the version of the serverless java packages. Also, a serverless workflow image is useless without its manifests, and those maninfests are not a random deployment.yaml, but rather a tool with we already supply. Connecting them together seems natural
After building a serverless workflow image the next step is to generate the operator-specific manifests for it. Today this is done using
kn-workflow gen-manifesttool and in a separate step. You need to create some pipeline (automation...) that willswf-builderkn-workflowstep 3 have a lot of room for mismatch and errors. the kn-workflow tool has a dependency on the sdk-go version of the serverless workflow api, and it must match with artifact the build the images. Also, every user that needs to create this sort of pipeline need to collect the right version of tool and create that automation themselves. Even with docs and examples there are no effective guardrails against mistakes.
Instead, I suggest that as part of the image creation process, the swf-builder would also produce the manifests and store them along the rest of the artifacts under the Runtime image:
After the image creation the automation can extract the /deployment/manifests/ dir from the image and store the in a config repository for example.
This kind of coupling is welcomed as it removes manual, error-prone steps from users. After all the manifests generation is coupled with the version of the serverless java packages. Also, a serverless workflow image is useless without its manifests, and those maninfests are not a random deployment.yaml, but rather a tool with we already supply. Connecting them together seems natural