Migrate away from Google project kubernetes-release-test

[ameukam]

The official releases and patch releases are currently done use a Google project where GCB builds are triggered. We should migrate to a community-owned project (preferably k8s-release).

• Migrate/rotate credentials needed for the release process
• Create/Replace GCP Service Accounts needed for the release process
• Create IAM bindings needed for the release process

/sig k8s-infra
/area infra/gcp
/priority important-soon
/milestone v1.30

[k8s-ci-robot]

@ameukam: The provided milestone is not valid for this repository. Milestones in this repository: [next, v1.25, v1.26, v1.27, v1.28, v1.29]

Use /milestone clear to clear the milestone.

In response to this:

The official releases and patch releases are currently done use a Google project where GCB builds are triggered. We should migrate to a community-owned project (preferably k8s-release).

• Migrate/rotate credentials needed for the release process
• Create/Replace GCP Service Accounts needed for the release process
• Create IAM bindings needed for the release process

/sig k8s-infra
/area infra/gcp
/priority important-soon
/milestone v1.30

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.

[k8s-ci-robot]

@ameukam: The label(s) area/infra/gcp cannot be applied, because the repository doesn't have them.

In response to this:

The official releases and patch releases are currently done use a Google project where GCB builds are triggered. We should migrate to a community-owned project (preferably k8s-release).

• Migrate/rotate credentials needed for the release process
• Create/Replace GCP Service Accounts needed for the release process
• Create IAM bindings needed for the release process

/sig k8s-infra
/area infra/gcp
/priority important-soon
/milestone v1.30

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.

[ameukam]

cc @kubernetes/release-engineering

[k8s-triage-robot]

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

This bot triages un-triaged issues 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 as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

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

/lifecycle stale

[xmudrii]

/remove-lifecycle stale

[ameukam]

/priority backlog
/milestone clear
/lifecycle frozen

[xmudrii]

I'll be looking into this
/assign

[BenTheElder]

I think we successfully did one with this? cc @ameukam

[ameukam]

Nope. Nothing started for this issue.

More docs:

• https://cloud.google.com/build/docs/securing-builds/configure-user-specified-service-accounts

[BenTheElder]

We should probably fix this in 1.34 ... cc @kubernetes/release-engineering @kubernetes/sig-k8s-infra-leads

AFAICT we just need to update the references to this project in kubernetes/release to point to a community project, and make sure we're using a community service account with write access to our bucket.

The current state makes me nervous that a release will at some point disrupted by some unseen google.com internal change (not a given, but who can say what happens to this project in the future).

I can help check any sig-k8s-infra bits, we need an agreement on timing to rotate, so we're aware of any potential issues for the next release. My suggestion is to do it when patch releases are slated and not a minor release.

[saschagrunert]

I agree we can probably do it at the beginning of the next cycle.