Today, every ConfigMap external resource definition mounted to the workflow pod is using the src/main/resources by default.

But a workflow might have the following definition:

{
"functions": [
    {
      "name": "isWinner",
      "operation": "specs/workflow-service-openapi.json#isWinner",
      "type": "rest"
    }
  ]
}

In a situation like this, the ConfigMap in the workflow annotation resource-openapi must have a key named "workflow-service-openapi.json" and the mount path must be src/main/resources/specs. Otherwise, the application will fail to find the given resource.

What we will do to provide more flexibility is to get rid of the "resources types" in the annotation and use the resources attribute instead in the KogitoServerlessWorkflow structure.

So in the example above, we have a ConfigMap like:

apiVersion: v1
data: 
  - supplier.yaml: ...
metadata: 
  name: openapi-configmap
kind: ConfigMap

And the workflow:

apiVersion: sw.kogito.kie.org/v1alpha08
kind: KogitoServerlessWorkflow
metadata: 
  name: serverless-workflow-service-calls-quarkus
  annotations: 
    sw.kogito.kie.org/description: Serverless Workflow Service calls example on k8s!
    sw.kogito.kie.org/version: 0.0.1
    sw.kogito.kie.org/profile: dev
spec: 
    flow: 
       - 
    resources: 
      - configMaps: 
             - name: openapi-configmap
                workflowPath: specs

In this example, the file supplier.yaml will be mounted in src/main/resources/specs/supplier.yaml

If not specified, the mount path will be in the root of src/main/resources.

The new workflowproj module (see KOGITO-9177) should also create the ConfigMaps according to this rule.