Update versions on stable branch

[remcowesterhoud]

Description

The maven action plugin used to only be able to update the version on the default branch of the repository. Recently a change has been made to make the branch configurable. For this reason a step has been introduced to the workflow to decide our git branch.

It works by first figuring out what the major and minor version of the release are (e.g. 1.4 when the release is 1.4.1). If this fails to yield a result we exit the workflow. Otherwise we will add the branch (stable/major.minor) as an output of this step. This will then be used by the community-action-maven-release as the branch for updating the versions.

I've done some manual test to verify the workflow works as expected. I did this by creating a stable/0.0 branch and creating some test release. I have deleted this branch and the releases by now, but the workflows are still available:

• Release on branch stable/0.0 with tag 0.0.1: https://github.com/camunda/zeebe-process-test/runs/5553684537?check_suite_focus=true
  Expected the workflow to create new commits updating the version on the stable/0.0 branch. ✅
• Release on branch stable/0.0 with tag release-0: https://github.com/camunda/zeebe-process-test/runs/5554164842?check_suite_focus=true
  Expected the workflow to fail, mentioning how the tag does not adhere to semantic versioning. ✅
• Release on branch stable/0.0 with tag 0.0.1-alpha1: https://github.com/camunda/zeebe-process-test/runs/5554214263?check_suite_focus=true
  Expected the workflow to create new commits updating the version on the main branch. ⚠️
  The test did not match the expectation. No new commits were created. After analysing why, the reason is that the release was created on the stable/0.0 branch. The community-action-maven-release has a check to see if the release tag is pointing to the latest commit on the target branch (main). This was not the case in my test, so my expectations were wrong. I can see in the logging that the correct branch (main) is being used. If the release would've been made on the main branch the workflow would've succeeded. Therefore, I consider this test a succes ✅

Related issues

closes #231

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

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

Documentation:

• Javadoc has been written
• The documentation is updated

[github-actions]

Unit Test Results

128 files  128 suites   5m 59s ⏱️
325 tests 325 ✔️ 0 💤 0 ❌
788 runs  788 ✔️ 0 💤 0 ❌

Results for commit 6b60d86.

[korthout]

LGTM 👍

Thanks for the comprehensive description of the problem and how it was solved. Complicated stuff, but it makes all sense to me now. Nice work! 👏

I only have 1 question about the case where the release is run from the main branch.

[korthout]

❓ What happens if gihub.ref equals refs/head/main? Can line 148 then set branch or does it just set it to null or so?

[remcowesterhoud]

That's a good point. It does not set anything, but it should set it to the default branch. Thanks for finding this bug 😄

[remcowesterhoud]

@korthout I know you already approved it last time, but it'd be great if you could have a look at the latest fix I did.

[korthout]

Awesome! Thanks @remcowesterhoud LGTM 🥳