Add workflow to release webhook in rancher/charts and rancher/rancher

[tomleb]

Issue rancher/rancher#46704

What is this

This adds two workflows that can be triggered manually to bump webhook RCs to rancher/charts and rancher/rancher.

Creating a new release in rancher/charts and rancher/rancher will be simple:

1. Go to the rancher/webhook repo
2. Click on the Actions tab
3. On the left sidebar, click on the workflow that you want to run.
4. Enter the necessary input. Example in the image below.
   
5. Click Run workflow

This will do the following.

charts

Create a new branch off of the branch you input, make some changes to bump webhook, push to rancher/charts directly (more details below), create a pull request to the target branch. You can see an example here: rancher/charts#4211.

rancher

Create a new branch off of the branch you input, update webhook version in build.yaml, run go generate, push rancher/rancher, create a pull request to the target branch. You can see an example here: tomleb/rancher-rancher#8.

Support

Currently, this supports the following:

• Bumping from one RC to another
• Bumping from one RC to unRC

It does not yet support adding an entirely new version of webhook. I'd be okay with implementing it for this PR if asked.

Benefits

• No need to open a terminal to do this work (tedious)
• Faster to create PRs: I made sure to include some relevant information to the PR description when they are opened. Here's an example:
  . I'm lazy so I'd rather not have to fetch this information every time like I've been doing and it should make it easier for reviewer as well to review this.
• Easier to review due to the above PRs containing lots of information and links
• This will also mean that we're going to need only 2 people for an RC bump because the PR will be created by the bot. So the person running the workflow + another person will be enough to review a bump.

Pushing to rancher/charts & rancher/rancher

EIO provided us with a GH app that can be used (through vault) to create tokens for rancher/rancher and rancher/charts. This allows us to push to those repositories directly and create PRs.

Credits

A lot of it was taken from the fleet team:

• https://github.com/rancher/fleet/blob/main/.github/workflows/release-against-charts.yml
• https://github.com/rancher/fleet/blob/main/.github/workflows/release-against-rancher.yml
• https://github.com/rancher/fleet/blob/main/.github/scripts/release-against-charts.sh
• https://github.com/rancher/fleet/blob/main/.github/scripts/release-against-rancher.sh

Some notable changes:

• Removed support from unRC and creating a new release entirely. Mostly to simplify, let's start with just bumping RCs which is what we end up spending most of our times on.
• Removed the need to input the chart version number (104.0.0 in 104.0.0+up0.5.0-rc13). Instead, we just reuse the one for that release.
• Removed the usage of the peter-evans/create-pull-request action. This has been explicitly rejected by the security team so we're not allowed to use it. Instead, using gh cli tool is good enough.
• More information in the PR description generated as mentioned above.

[ericpromislow]

Regarding the env vars, once this is out of draft and ready to play with I'll see if I can trigger an exploit

[tomleb]

Adapted from https://github.com/actions/create-github-app-token, unsure how necessary this is, probably not, but I guess that's probably the "idiomatic" values to put there so why not

[tomleb]

Updated the workflow so they use a github apps credential provided by EIO instead. No need for a fork anymore, can directly push to our repos.

[tomleb]

We could also avoid requiring the old version of webhook and instead fetch it directly from that same file. I'd be okay with that. This way you'd just need to know the version you want to go to.

[pmatseykanets]

Is there any benefit in using dapper for this? Perpetuating the use of dapper seems suboptimal.

[tomleb]

Discussed this on slack but for visibility:

go generate might use a few tools like go and controller-gen. Those tools version are currently only defined in the Dockerfile for dapper in r/r. I want to be able to generate using the right tools, so using dapper for now is convenient because we don't need to care about those tools, no need to keep maintaining and syncing them with r/r, etc.

I don't really have bandwidth for making a change in r/r to allow that (eg: by extracting the versions of tools outside).

[pmatseykanets]

Do we need to go generate everything here or intent was only to call go run ./pkg/codegen/buildconfig/...?

[tomleb]

I could extract the commands that go generate runs but I think it's more future proof to use go generate directly. The tradeoff is that this takes longer to run (which also means preventing other jobs to run).

[pmatseykanets]

It also has potential of failing doing the irrelevant work.

[tomleb]

I'll leave as is for now.

[nflynt]

Looks mostly okay to me. If we can make the new RC handling a tiny bit more robust I think I have no other changes to add. Mostly we want to make it impossible/difficult for newly onboarded engineers to accidentally blast build artifacts. :)

[tomleb]

Updated the release against charts script to support going from stable release to new rc (eg: v0.5.2 to v0.5.3-rc.1). I have tested it locally and that seems to work fine.

[nflynt]

This looks good to me. Now that the RC guards are in place, nothing's really jumping out. We can improve it further as we go. 👍