org
org copied to clipboard
kubernetes
Enable Google Cloud build on kubernetes/minikube repo
Hello I would like to enable Google Cloud Build CI on minikube repo, I created an issue here https://github.com/kubernetes/org/issues/2716
but I was directed to this repo. I hope I am requesting at the right place:
Organization or repository kubernetes/minikube
Name of integration google cloud build
Link to integration website https://cloud.google.com/build
Describe what is attempting to be accomplished we would like to be able to use google cloud build in minikube ci/ci process, so our internal jenkins can be moved to a cloud build yaml config in github, without having to move our google cloud credentials (used for publishing binaries and images) outside google cloud project .
Additional context for request kubernetes/minikube#11436
@medyagh Can you describe us the release process ? It's not clear to me what exactly need to be migrated. My first understanding (I may be wrong) is that we will need a new GCP project where you can run jobs for the minikube releases.
hi @ameukam this is merely on the Github Permissions to add "google cloud build app" to be added to the org, so we can use it in our release process through github
without having to move our google cloud credentials (used for publishing binaries and images) outside google cloud project .
@medyagh Few questions:
- IIUC the GCP project is not community-owned, correct? In that case, like @ameukam mentioned, would we need to create a new GCP project for minikube? Would be helpful if you could elaborate on the release process :)
- Why can't prow be used here?
without having to move our google cloud credentials (used for publishing binaries and images) outside google cloud project .
@medyagh Few questions:
- IIUC the GCP project is not community-owned, correct? In that case, like @ameukam mentioned, would we need to create a new GCP project for minikube? Would be helpful if you could elaborate on the release process :)
not sure which definition of community-owned is being referred here. for minikube's binaries and ISOs we use a GCP project. we have a task to move this to a community categorization inside GCP. (vs internal) @sharifelgamal is working on that.
- Why can't prow be used here?
historically we have used k8s-minikube GCP project to host the minikube binaries and ISO, and the release process is done through an internal tool inside google. our goal is to move this to a process transparent to the community so non-googlers can maintain minikube too without having access to internal release infrastrucutre. for that reason we have decided to try google cloud build in the same GCP project so we don't need to move our GCP credentials outside.
not sure which definition of community-owned is being referred here.
community-owned = owned by the upstream k8s community (wg-k8s-infra) and not restricted to only googlers
we have a task to move this to a community categorization inside GCP. (vs internal) @sharifelgamal is working on that.
This is great to hear!
Similar to the concerns brought up in the slack thread, we would prefer not to set up an integration for a GCP project that's not owned by the community.
Our preference would be to use prow since that's what's used across many different projects in the kubernetes/kubernetes-sigs GitHub orgs. If prow won't work, we can work with wg-k8s-infra to get a community-owned GCP project.
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/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas 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
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/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas 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
/remove-lifecycle rotten
I don't think we can move forward with this. For the moment: /lifecycle frozen
/remove-lifecycle frozen /close
Closing stale issue. please reopen if there is still discussion.
@cblecker: Closing this issue.
In response to this:
/remove-lifecycle frozen /close
Closing stale issue. please reopen if there is still discussion.
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.
