Reusable build docker action

[npepinpe]

Description

This PR aggregates the steps required to build the Docker image into a reusable action called build-docker. The action can build and push the Docker image, as well as package the artifacts for it if need be.

Further iterations may want to split packaging out into its own action.

Its usage is as:

- uses: ./.github/actions/build-docker
  with:
    repository: localhost:5000/camunda/zeebe
    version: current-test
    push: true
    package: true

The action will set up Docker & Buildx, Java, and Maven. If package is true, it will also setup Go in order to build zbctl.

When push is true, the image is pushed to the given repository, with the tag being made of the repository and version. In the above, this would be equivalent to docker push localhost:5000/camunda/zeebe:current-test. If push is false, then the image is built and loaded into the local Docker registry only.

If package is true, then zbctl is compiled, and all the modules are built and installed to the local maven repository. Additionally, the distribution TAR ball is built. If it's false, then the distribution TAR ball is expected to already be present under dist/target/camunda-zeebe-<VERSION>-tar.gz.

If the version is omitted, it will be read from the Maven project.

Related issues

related to #10013 (as a follow up)

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.

[npepinpe]

One thing to note here, the action doesn't work on self hosted runners. It could be made to work by setting up buildx here (or already in our self hosted runner), like on the ubuntu-latest GitHub runner. I tried 5 minutes and it didn't work, and I figured it wasn't critical yet, but let me know.

[github-actions]

Test Results

   812 files  +  1     812 suites  +1   1h 38m 2s ⏱️ - 5m 52s
6 093 tests  - 36  6 082 ✔️  - 37  10 💤 ±0  1 ❌ +1 
6 273 runs   - 44  6 262 ✔️  - 45  10 💤 ±0  1 ❌ +1 

For more details on these failures, see this check.

Results for commit e76b855. ± Comparison against base commit 7f1134c.

♻️ This comment has been updated with latest results.

[npepinpe]

I still have to test the deploy, btw, but I could use a pair of eyes to validate the approach.

[oleschoenburg]

Bummer that we can't use it on self-hosted runners. Do you think a second pair of eyes would help to set it up?

The overall approach looks good to me, it's exactly how I imagined it would look like. I can't think of anything that would be problematic or that could be improved.

[npepinpe]

So we can make it work on self-hosted runners in two ways:

1. Have buildx setup already, like with the GitHub hosted runners
2. Install and setup buildx. I just tried using the provided action and it wasn't enough, and I just didn't want to spend more time there. It can definitely be a refinement if we need it, but I'm not sure yet that we need it.

[npepinpe]

@oleschoenburg I think I got it to work on self-hosted runners. So our integration tests will also build it, and I've set it up so they will also package the application in the same step, but I feel that might be too opaque. I'm thinking we might want (but not here) to continue building reusable actions, e.g.

• setup-zeebe (setup java, go, maven)
• package-zeebe (build go, build java)
• build-docker (build docker image from package-zeebe outputs)

I think these are the most common "blocks" we have everywhere. Benefits are centralizing the Maven/Java/Go versions and how the artifacts are built. Downside is things start being a little more "hidden" =/

[npepinpe]

There was a known flaky test, but the rest looks OK. Let me know what you think.

[oleschoenburg]

Awesome, looks good to me 👍
Just two minor comments.

[npepinpe]

bors merge

[zeebe-bors-camunda]

Build succeeded:

• Test summary
• Java checks
• Go linting