feat: create automated pull requests for new Kimai Versions

[cngJo]

This PR uses the peter-evans/create-pull-request action to create a new Pull Request and a simple script based on awk to update the version number in _config.yml.

In the current version.yml workflow, you used ${{steps.remote_version.outputs.version}} to get the version number. I'm not sure where this comes from. Therefore, I've adjusted the action to expect a payload kimai_version containing the new kimai version.

Since this requires a small change to the workflow in kimai/kimai I've created a small Pull Request for the changes there as well: kimai/kimai#4248

I've tested this on my fork, by sending the Webhook for the repository_dispatch manually using this script:

#!/usr/bin/env sh

set -e

if [ $# -ne 2 ]; then
    echo "Usage: $0 <github-token> <new_value>"
    exit 1
fi

token="$1"
new_value="$2"

curl -L \
  -X POST \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer ${token}" \
  -H "X-GitHub-Api-Version: 2022-11-28" \
  https://github.com/repos/cngJo/www.kimai.org/dispatches \
  -d "{\"event_type\":\"kimai_release\",\"client_payload\":{\"kimai_version\":\"${new_value}\"}}"

./test-send-webhook.sh <github-token> "2.0.31"

This created the following Pull Request: cngJo#1

I've tried to use sensible defaults for commit messages and branch names. Please let me know when you have any other suggestions 😉

---

ATTENTION:

Please make sure the default GITHUB_TOKEN write access and permissions to create Pull Requests.
See Workflow Permissions in the create-pull-request repo for more information.

[kevinpapst]

Not sure about the token, I might have to update it.

We'll see in a second 😁

[kevinpapst]

We should add some validation here as well, if everyone can trigger the workflow.

[cngJo]

Adding validation sounds like a good idea, but I'm not sure what the best was to this would be.

We could add a common secret as some sort of "password" to both repositories and validate them in the action.

So pass a second payload parameter to the dispatch and compare it against a secret in the repository. This will still allow everyone to trigger the pipelines, but they would fail and not spam Pull Requests :D

Over in kimai/kimai we could store that "password" also in a secret and add a second required field to the workflow_dispatch, so everyone that knows the "password" can still trigger it manually.

What do you think?

[cngJo]

Not sure about the token, I might have to update it.

Since we are using the token that GitHub provides automatically for actions (default behavior of peter-evans/create-pull-request when not specifying a token), you can configure its permission in the repository settings.

For this repository, it would be in https://github.com/kimai/www.kimai.org/settings/actions at the very bottom of the page.

For my fork, I have changes it to having write access and being able to create pull requests: