Create permanent `pr-deploy` branch

[c-pius]

Description

:exclamation: FIRST verify with SRE that the concept below can be achieved.

Create a permanent pr-deploy branch and PR in management-plane-charts repository. Every time we merge a commit on lifecycle-manager:main, we want the branch/PR to be updated automatically with the new commit hash so that the changes are deployed continuously for testing.

Acceptance Criteria

• [ ] clarified with SRE if the last deployment from this PR can be sticky or at what frequency it will be overwritten by a sticky deployment (i.e., latest semver release)
• [ ] branch / PR created targeting charts/lifecycle-manager branch
  • reasonable name chosen
  • do not merge label added
  • pr-deploy label added
• [ ] branch / PR is automatically updated with changes from lifecycle-manager:main
  • found out how to sync the changes automatically (e.g., via a webhook triggered on commits on lifecycle-manager:main)
  • found out how to get the needed image tags
  • found out how to bump the chart version automatically (always needs to be higher than the latest chart version on charts/lifecycle-manager)

Reason

We want to have our changes to lifecacle-manager:main continuously deployed to DEV for testing

[jeremyharisch]

I have clarified with the SREs with the following output:

• The image, from a PR in management-plane-charts will be deployed until a new version arrives. That could be another pr-dev, or a normal version bump
• Deployed pre-releases are not subject to promotion, allowing for testing and refining changes.
• To trigger this functionality, add the pr-deploy label to the pull request in the management-plane-charts repository.
• Once labeled, each commit to the chart will be packaged with a pre-release tag and deployed to kcp-dev.
• Deployed pre-releases are not locked, allowing other deployments to override them.
• Upon merging the pull request, the final release will override the pre-release version.
• Argopromote version 1.4.0 includes a reset subcommand to revert to the last successfully deployed version.

[c-pius]

Deprioritized this as it is not a current pain point. We can look at it later again if we find that automatic deployments to DEV ease our dev process.

[jeremyharisch]

To trigger a GitHub Actions workflow in Repository B when a commit is pushed to Repository A, you'll need to use a combination of GitHub Webhooks and a personal access token (PAT) to trigger the workflow in the second repository. Here's how you can do it:

Steps:

1. Set up a Webhook in Repository A:

• Go to Repository A on GitHub.
• Navigate to Settings > Webhooks.
• Click on Add webhook.
• In the Payload URL field, enter the URL for triggering a GitHub Actions workflow via the GitHub API. The URL will look something like this:

   https://api.github.com/repos/<owner>/<repository>/dispatches

  Replace <owner> and <repository> with the appropriate values for Repository B.

• Set the Content type to application/json.
• In the Secret field, enter a secret (optional, but recommended for security).
• Under Which events would you like to trigger this webhook?, select Just the push event (or specify any other relevant events).
• Click Add webhook.

2. Create a Personal Access Token (PAT):

• Go to your GitHub Profile > Settings > Developer settings > Personal access tokens.
• Generate a new token with the repo scope, which allows access to public and private repositories.
• Save the token somewhere safe, as you’ll use it in the workflow file in Repository A.

3. Configure GitHub Actions Workflow in Repository A:

In Repository A, create or update your GitHub Actions workflow file (.github/workflows/trigger-repo-b.yml).

Example workflow file:

   name: Trigger Repository B Workflow

   on:
     push:
       branches:
         - main  # Adjust the branch as needed

   jobs:
     trigger-workflow:
       runs-on: ubuntu-latest

       steps:
         - name: Trigger Repository B workflow
           run: |
             curl -X POST \
             -H "Authorization: token ${{ secrets.PERSONAL_ACCESS_TOKEN }}" \
             -H "Accept: application/vnd.github.everest-preview+json" \
             https://api.github.com/repos/<owner>/<repository>/dispatches \
             -d '{"event_type": "trigger_workflow"}'
           env:
             PERSONAL_ACCESS_TOKEN: ${{ secrets.PERSONAL_ACCESS_TOKEN }}

• Replace <owner> and <repository> with the values for Repository B.
• Ensure you add the generated Personal Access Token as a secret named PERSONAL_ACCESS_TOKEN in Repository A.

4. Create a Workflow in Repository B:

In Repository B, create a GitHub Actions workflow file that gets triggered by the external event from Repository A.

Example workflow file (.github/workflows/on-dispatch.yml):

   name: On Dispatch Event

   on:
     repository_dispatch:
       types: [trigger_workflow]

   jobs:
     build:
       runs-on: ubuntu-latest
       steps:
         - name: Checkout Repository B
           uses: actions/checkout@v2

         - name: Run some action in Repository B
           run: echo "This is triggered by a push in Repository A"

Summary:

1. Repository A has a webhook that triggers when a push event occurs.
2. Repository A's GitHub Actions workflow sends a request to Repository B using the GitHub API.
3. Repository B listens for the repository_dispatch event and runs its workflow.

This setup ensures that a push in Repository A triggers a workflow in Repository B.

[jeremyharisch]

We have adapted our current release process timeline. We need to check if this already solves our release process problems. Until then, this ticket can be parked.