Task: Unify GH App token setup

[maximiliantech]

Description

We have inconsistencies in across our repositories in the openmcp-project org.

Deploy Keys vs. GH Apps

Most of the time, we are using Deploy Keys to push certain information/changes to a repository, e.g. https://github.com/openmcp-project/mcp-operator/blob/87211ccb1a65a46dbb494279f402c3453ed46e3e/.github/workflows/release.yaml#L135-L143
This setup was done with the first round of open sourcing our repositories.

With new repos to come, we have to manually generate a public/private key pair on your local machine and add these to the repo settings (one-time activity more or less), see e.g. https://github.com/openmcp-project/mcp-operator/settings/keys and https://github.com/openmcp-project/mcp-operator/settings/secrets/actions.

Solution

In a discussion with @ValentinGerlach, @maximiliantech invested some time to figure out whether we could change our Deploy Key setup with a GitHub Apps. With GH Apps we reach the same goal: We have a secret/token available in a GH Action that we can use to push changes to the repo AND the GH App can be added to a bypass list in order to properly bypass branch protection rules.

We played a bit around and the result can be seen in https://github.com/openmcp-project/cluster-provider-kind and https://github.com/openmcp-project/cluster-provider-gardener. There, we are using a GH App called openmcp-ci. That App has a permissions to read/write code in a repository.

Task

The task is to change this setup for the rest of the repos in the whole organization.

Any further valuable resources.

The changes that are needed to fullfil this task can be seen in these examples:

• feat(ci): use GH App token cluster-provider-kind#17
• feat(ci): use GH App token cluster-provider-gardener#22

What is required to accept the Task as done.

Done Criteria

• All repositories are using the GH App openmcp-ci
• GH Actions are adjusted to the new setup and using generated tokens by the openmcp-ci App
• Add this setup to our documentation (to have an easier setup for next open source repos that get created)

[In-Ko]

Not sure about the current priority of this. Let's briefly talk in one of the upcoming refinements.

[In-Ko]

please update accordingly

[maximiliantech]

We are already using shared workflows in all our operator repositories. Therefore, all deploy tokens were not be used anymore for several weeks. Now, I removed the remaining deploy keys in all of the repositories that were brought open source with this mechanism initially.

All new operators, will look the same and will use the shared workflows out of the box.

This issue is not longer needed and can be closed.