Migrate Repositories to kcp-Prow

[xrstf]

This is a checklist for keeping track of the kcp-dev/* repos on Github and their migration to kcp's own Prow:

### Repositories
- [ ] https://github.com/kcp-dev/infra/issues/42
- [ ] https://github.com/kcp-dev/infra/issues/27
- [ ] https://github.com/kcp-dev/awesome-kcp
- [ ] https://github.com/kcp-dev/infra/issues/32
- [ ] https://github.com/kcp-dev/infra/issues/29
- [ ] https://github.com/kcp-dev/infra/issues/30
- [ ] https://github.com/kcp-dev/infra/issues/31
- [ ] https://github.com/kcp-dev/infra/issues/48
- [x] https://github.com/kcp-dev/enhancements
- [ ] https://github.com/kcp-dev/friends
- [ ] https://github.com/kcp-dev/infra/issues/28
- [ ] https://github.com/kcp-dev/infra/issues/43
- [ ] https://github.com/kcp-dev/kcp-dev.github.io
- [ ] https://github.com/kcp-dev/kcp.io
- [ ] https://github.com/kcp-dev/infra/issues/33

Repositories not to be migrated

• https://github.com/kcp-dev/catalog
• https://github.com/kcp-dev/cel-go
• https://github.com/kcp-dev/kcp-glbc
• https://github.com/kcp-dev/kcp-tests
• https://github.com/kcp-dev/kubernetes

[nikhita]

Happy to help out here as well :)

[xrstf]

How can we coordinate on this? I need to setup the Prow stuff and the webhook, but then afterwards anyone can make the PRs to add the .prow.yaml files everywhere.

[nikhita]

How can we coordinate on this? I need to setup the Prow stuff and the webhook

re: webhook - out of curiosity, why aren't we adding the webhook at the org level?

re: setting up prow - #26 takes care of it, right? are there additional things required?

[xrstf]

re: webhook - out of curiosity, why aren't we adding the webhook at the org level?

Never done that, only recently learned that this works, plus I have no access to org-level settings 😁 In general I don't see an issue with doing it for the entire org.

re: setting up prow - #26 takes care of it, right? are there additional things required?

The other things are

• adding a .prow.yaml (for example like in 🌱 Add .prow.yaml, migrate to kcp-prow logicalcluster#35)
• converting existing Prowjobs from Openshift CI to kcp Prow
• removing the ci-operator.yaml config
• removing the repository from openshift/release, like remove configuration for kcp-dev/logicalcluster openshift/release#39639

[xrstf]

In the meantime, for the repos in the checklist above: If there is a dedicated ticket, that means the webhook is setup and someone can pick it up and work on that repo.

[palnabarun]

How about we centralize the job configuration in this repo? That way all configs stay at the same place and review/approvals can be governed by OWNERS files.

[palnabarun]

Kubernetes also follows the same approach in kubernetes/test-infra

[xrstf]

In my experience having jobs in a central location becomes a problem when the repos start branching heavily and maintaining the correct config files for each branch of each repo centrally -- I never liked that and welcomed the in-repo config sooo much.

I also don't think the infra-maintainers should approve Prowjobs of, say, the logicalcluster repo.

[palnabarun]

Overall, I do agree that both approaches have their pros and cons.

maintaining the correct config files for each branch of each repo centrally

I am not sure I understand this problem very clearly.

I also don't think the infra-maintainers should approve Prowjobs of, say, the logicalcluster repo.

The infra-maintainers don't need to be in the loop for all repos. Maintainers of each repo can themselves approve Prowjobs for their repo jobs.

---

I am okay with whatever is decided. I wanted to understand out of satisfying curiosity.

[xrstf]

Oh, maybe I have misrepresented my thoughts, but I am also not completely against centrally managed jobs. A healthy mix is what I would have aimed at, with most focus on in-repo jobs.

I am not sure I understand this problem very clearly.

In our product, we did a few major code reorganizations, where for example a command: ./hack/ci-test-e2e.sh from a Prowjob in product v1.x would need to be command: ./hack/ci/test-e2e.sh in v2.x.

This lead to lots of if [ -f ... ] blocks and impromptu shellscripts in our Prowjobs and it turns out that instead of trying to maintain one set of jobs for all branches centrally in the infra repo, it's easier to just have the jobs for one branch live in that one branch of that repo.

Sure, we could have copied the jobs, or wrote some more tooling to generate them, but this all seemed like even more overhead.

Centrally managed jobs shine often for postsubmits and they are a nice way to impose certain minimum jobs for each repo (like we do here with the validate-prow-yaml) that must pass before in-repo jobs are even started.

[palnabarun]

Got you! Thanks for the context @xrstf! 💯

[xrstf]

But I can also see the downsides of in-repo. Like when you need to change that one tiny thing, but in all branches in all of your repos, and you spend the rest of the opening PRs and frying the CI cluster. So yeah, centrally managed jobs can be godsend, too. :)