Add possibility to build custom Kubernetes forks

[saschagrunert]

What type of PR is this?

/kind feature

What this PR does / why we need it:

This patch adds the possibility to use the environment variables K8S_ORG, K8S_REPO and K8S_REF to specify a custom Kubernetes fork for building releases. It is not possible right now to krel release them. But staging for testing and artifact discovery is a common use cases when changing the build infra in k/k.

Which issue(s) this PR fixes:

Fixes #1883

Special notes for your reviewer:

None

Does this PR introduce a user-facing change?

Added `K8S_ORG`, `K8S_REPO` and `K8S_REF` environment variable support to stage custom k/k forks.

[saschagrunert]

Testing with kubernetes/kubernetes#102126 and kubernetes/kubernetes#102125:

> export TOOL_ORG=saschagrunert \
    TOOL_REF=custom-k8s \
    K8S_ORG=saschagrunert \
    K8S_REF=automated-cherry-pick-of-#98529-upstream-release-1.19 && \
    go run ./cmd/krel stage --branch release-1.19 --type=official

https://console.cloud.google.com/cloud-build/builds/a743e675-554d-46b5-a89a-373ba1a93b40?project=kubernetes-release-test

> export TOOL_ORG=saschagrunert \
    TOOL_REF=custom-k8s \
    K8S_ORG=saschagrunert \
    K8S_REF=automated-cherry-pick-of-#98529-upstream-release-1.20 && \
    go run ./cmd/krel stage --branch release-1.20 --type=official

https://console.cloud.google.com/cloud-build/builds/fbb03860-7e77-4f27-8953-34885dd8d18f?project=kubernetes-release-test

[saschagrunert]

We could think about making those variables real flags in krel, which would allow us adding some documentation as well as use cases around them.

[saschagrunert]

Ready for some first thoughts 🙃

[puerco]

I wanted to hook up during the week to talk about this but I was buried in work. It looks good to me obviously, but I'm curious about the use case. HOw are you planning to use it? 🤔

[justaugustus]

Same question as Adolfo!
Let's discuss next week. :)

[saschagrunert]

I wanted to hook up during the week to talk about this but I was buried in work. It looks good to me obviously, but I'm curious about the use case. HOw are you planning to use it?

The use case would be, that if I change a code part in k/k which affects the way how we build releases, then I'm now able to verify those changes by staging a custom release from my fork.

Another (future) use case could be, that as a maintainer of a custom k/k fork, I'm now able to cut releases within community infra. This is a different discussion where we have to decide if we wanna go that far, but in theory it would be possible.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-ci-robot]

@saschagrunert: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
pull-release-image-kpromo	a018f48	link	/test pull-release-image-kpromo

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[justaugustus]

@saschagrunert -- Can you rebase?

[saschagrunert]

Rebased and tested manually.

[justaugustus]

Awesome. Thanks @saschagrunert!

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: justaugustus, saschagrunert

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [justaugustus,saschagrunert]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment