-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Split prow config from prow codebase #11782
Comments
/assign |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
/remove-lifecycle stale |
Need to see what PR's modify config.yaml and plugin.yaml and decide if we want those to go through rebase fun |
/milestone v1.16 |
/assign @cjwagner |
Rescoping based on what we thought was feasible for this quarter, moving to its own repo can be done as a followup |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
/remove-lifecycle stale |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
/remove-lifecycle stale
sounds relatively easy, maybe we should do that. @cjwagner @fejta thoughts?
you actually just have to file an issue in k/org after getting consensus from the SIG on wanting it, no KEP necessary. the process is pretty lightweight. moving code is a little more involved to do cleanly. |
Moving prow/cluster files into config/prow or somewhat like that sgtm |
/area prow |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
/remove-lifecycle stale I think this is mostly done? pretty much everything is under
we can actually do this with much less than a KEP, SIGs can sponsor a repo without going full KEP 🙃 |
I don't think there's any config lingering under prow/ now. some scripts / makefile stuff. |
Yeah, the config is pretty much moved out of the prow directory. What would be needed to move prow into its own repo is:
The point that is presumably most of the work is setting up the jobs on the new repo. It would be great to make this happen though, to better separate concerns and make certain tasks like updating dependencies easier 🙃 |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
Stale issues rot after 30d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or fejta. |
/remove-lifecycle rotten |
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-contributor-experience at kubernetes/community. |
/remove-lifecycle stale |
We have https://github.com/kubernetes-sigs/prow which could host the codebase. Currently it just holds Prow docs but most of the code there sits under a /site folder so it should be straightforward to move code in there (I expect us to basically do
I think at least for the jobs that publish new Prow images, they can be set up to use the code from the new repo and still publish into the same GCR locations, because the SHAs would be different so there wouldn't be any overlap. Once all of the presubmits and integration tests are set up to work on the new repo, I assume it would be OK to put a blockade on the old repo's I assume no one is currently working on this effort. But I am interested in this space. |
This old issue got lost but https://github.com/kubernetes-sigs/prow exists now. |
We're getting close to being ready for the move. Items we know we need to accomplish is here:
config/
and run theconfig-bootstrapper
in case any changed had landed in between [WIP] Move configuration files to their new home #11784prow/cluster
toconfig/cluster
prow/cluster
is updated/cc @spiffxp @fejta @cjwagner @BenTheElder @krzyzacy
The text was updated successfully, but these errors were encountered: