A selected set of serverless workflows.
Here is the layout of directories per workflow. Each folder contains at least:
application.properties
the configuration item specific for the workflow app itself.${workflow}.sw.yaml
the serverless workflow definitions with respect to the best practices.specs/
optional folder with OpenAPI specs if the flow needs them.All .svg can be ignored, there's no real functional use for them in deployment and all of them are created by VSCode extension.
Every workflow has a matching container image pushed to quay.io by a github workflows
in the form of quay.io/orchestrator/serverless-workflow-${workflow}
.
After image publishing, GitHub action will generate kubernetes manifests and push a PR to the workflows helm chart repo under a directory matching the workflow name. This repo is used to deploy the workflows to an environment with Sonataflow operator running.
Follow these steps to successfully add a new workflow:
/onboarding
application.properties
, onboarding.sw.yaml
into that folder.github/workflows/${workflow}.yaml
that will call main
workflow (see greeting.yaml)charts/workflows/charts/onboarding
. You can copy the greeting sub-chart directory and files.See Continuous Integration with make for implementation details of the CI pipeline.
There are two builder images under ./pipeline folder:
docker.io/apache/incubator-kie-sonataflow-builder:main
that doesn't required any authorizationNote on CI: For every PR merged in the workflow directory, a GitHub Action runs an image build to generate manifests, and a new PR is automatically generated in the serverless-workflows-config repository. The credentials used by the build process are defined as organization level secret, and the content is from a token on the helm repo with an expiry period of 60 days. Currently only the repo owner (rgolangh) can recreate the token. This should be revised.