support invoking as a cli

[nhomble]

Is your feature request related to a problem? Please describe.
I am frustrated that my bpmn definitions need to live as junit resources. We are interested in building an independent sdlc for our bpmn deployments, but to reuse this testing framework we'd have to modify the junit tests as well.

Describe the solution you'd like
I'd like to have a separate CLI that took parameters for not only the bpmn resources but all the connectivity information as cli args so that I could execute as part of a pipeline like github actions or gitlab ci.

Describe alternatives you've considered
We've considered just housing all of our bpmn in a kotlin project and having our bpmn deployment look at a resources directory.

Additional context
N/A

[saig0]

@nhomble thank you for raising this up 👍

Please elaborate more on the CLI that you have in mind.
Which arguments do you expect?
How should it be integrated? (e.g. Maven plugin, standalone app)

[nhomble]

Please elaborate more on the CLI that you have in mind.

I'm hoping to integrate the cli in a gitlab runner for a bpmn/dmn pipeline into zeebe. zbctl makes it easy to do the deployment from a runner, but I'd like to assert some tests before a process modeler/author deploys the new code.

Which arguments do you expect?

I'd imagine something like

$ bpmn-spec --zeebe-host https://zeebe:8080 --zeeqs-host https://zeeqs:8080 --resources ./path/to/bpmns --specs ./path/to/yml/specs

(super rough idea). In the readme, when I see

        val testResult = specRunner.runSingleTestCase(resources = spec.resources, testcase = spec.testCase)

        Assertions.assertThat(testResult.success)
                .describedAs("%s%nDetails: %s", testResult.message, testResult.output)
                .isTrue()

I see the cli wrapping all this junit ceremony and just return a non-zero exit code when testResult is not success.

How should it be integrated? (e.g. Maven plugin, standalone app)

I'd prefer standalone, but curious about the benefits for a maven plugin. In other plugins, I've seen argument passing to maven plugins get pretty gnarly so maybe we don't wanna constrain ourselves there.

[saig0]

@nhomble thank you for providing the insides.

I'm curious. Why do you want to configure the Zeebe and ZeeQS endpoint?
In the regular setup, Zeebe and ZeeQS would be spawned by bpmn-spec itself.

[nhomble]

I guess you could still support creating the supporting services via cli, but I can imagine other users being stuck with docker-in-docker restrictions. Might be good to allow pipeline developers to override as needed.