Common reusable actions

[npepinpe]

Description

This PR aggregates the steps to set up the Zeebe environment for packaging, as well as packaging itself, into two reusable actions. By doing this, it removes the duplicate code in the build-docker action, and instead relies on the caller having set up and packaged Zeebe beforehand (much like we rely on the checkout step being invoked before).

setup-zeebe will prepare the environment to build the complete Zeebe distribution. The benefits here is that we centralize once the tech stack, how it's installed, and the versions we require, instead of spreading this everywhere. I've made it configurable so some parts can be ignored, primarily because of the setup-go action. If you use that, but do not do anything with Go, it will fail in its post-run when trying to clean a non-existent cache 🤷 The action requires the code to have been checked out beforehand.

build-zeebe will build the Go client (optional) and the Java distribution (optional). By default, it builds everything. It also requires the environment to be set up beforehand, and the code checked out. It uses the clients/go/cmd/zbctl/build.sh script to build the Go client, and will install the mvn modules, skipping checks and using -T1C to parallelize by default. You can customize the installation via a free-form field letting you set up additional properties to pass to the build. The benefits here is again centralization of the common set up, while allowing enough customization for the various steps.

I decided to split both set up and packaging because there are some places where we package the application differently, notably when deploying/releasing. As this will most likely be used in the future for releases, it made sense to me. So the packaging is really more of a "package for non-release cases". It could be changed to allow us to modify the command for packaging (right now you can only pass options, but cannot change the actual goals to execute), and then I suppose it could be reused. I think it might be misleading though to have a build Zeebe action which actually deploys, so I'd rather avoid that for now.

Related issues

related to #10017

Definition of Done

Not all items need to be done depending on the issue and the pull request.

Code changes:

• The changes are backwards compatibility with previous versions
• If it fixes a bug then PRs are created to backport the fix to the last two minor versions. You can trigger a backport by assigning labels (e.g. backport stable/1.3) to the PR, in case that fails you need to create backports manually.

Testing:

• There are unit/integration tests that verify all acceptance criterias of the issue
• New tests are written to ensure backwards compatibility with further versions
• The behavior is tested manually
• The change has been verified by a QA run
• The impact of the changes is verified by a benchmark

Documentation:

• The documentation is updated (e.g. BPMN reference, configuration, examples, get-started guides, etc.)
• New content is added to the release announcement
• If the PR changes how BPMN processes are validated (e.g. support new BPMN element) then the Camunda modeling team should be informed to adjust the BPMN linting.

Please refer to our review guidelines.

[github-actions]

Test Results

   843 files  ±  0     843 suites  ±0   1h 36m 36s ⏱️ + 1m 13s
6 353 tests  - 62  6 342 ✔️  - 62  11 💤 ±0  0 ❌ ±0 
6 537 runs   - 62  6 526 ✔️  - 62  11 💤 ±0  0 ❌ ±0 

Results for commit e5d9f43. ± Comparison against base commit 95f1f25.

♻️ This comment has been updated with latest results.

[npepinpe]

The setup-go action fails when there is nothing cached. So if we setup Go all the time (for simplicity's sake), it will fail if there are steps where nothing was cached, and they run before something was cached for this cache key. I guess we do have to make it optional, then.

[npepinpe]

One interesting thing to note, is that the setup/build actions could probably be merged under the current conditions. We almost never really do one without the other (only on deploy do we do build/install differently), and there is a clear dependency between the build and setup (plus, if you disable Java/Go in one, you have to disable it in the other). But I'm not sure if that's a good idea long term, and I like the flexibility of having multiple small actions (plus they're easier to understand individually). If you combine them both, then you as you need more flexibility (different java versions, different Go versions, etc.), then you start having an action with tons of inputs that just delegates to other actions. It seems rather cumbersome, to some extent.

I also don't want to go too much into having many tiny actions, I think that'll just create more confusion than anything.

Also note that we could cut down on a bunch of flexibility I added here. For example, we never change the Java/Go versions, or the Maven version, so we could remove those inputs. This would make merging both actions a bit simpler, since you only have one param per language (enable go, enable java) 🤷

[lenaschoenburg]

Thanks @npepinpe, this looks great 😍

I have one blocking question regarding javadocs that we should resolve before merging though.

[npepinpe]

bors merge

[zeebe-bors-camunda]

Build succeeded:

• Test summary
• Go linting
• Java checks