search

kcp-dev / infra

CI infrastructure
Apache License 2.0
6 stars 11 forks source link

Migrate Repositories to kcp-Prow #25

Closed xrstf closed 4 months ago

xrstf commented 1 year ago

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

nikhita commented 1 year ago

Happy to help out here as well :)

xrstf commented 1 year ago

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 commented 1 year ago

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 - https://github.com/kcp-dev/infra/pull/26 takes care of it, right? are there additional things required?

xrstf commented 1 year ago

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 :grin: In general I don't see an issue with doing it for the entire org.

re: setting up prow - https://github.com/kcp-dev/infra/pull/26 takes care of it, right? are there additional things required?

The other things are

xrstf commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

xrstf commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

Got you! Thanks for the context @xrstf! 💯

xrstf commented 1 year ago

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. :)

nikhita commented 1 year ago

Once all repos have been migrated, maybe we could create a single PR to remove the repos from openshift/release to make approvals easier?

xrstf commented 1 year ago

I fear that if we leave some repos in both Prows, outside contributions might be problematic. Not sure though, but that was my reason for doing it individually per-repo.

kcp-ci-bot commented 6 months ago

Issues go stale after 90d of inactivity. After a furter 30 days, they will turn rotten. Mark the issue as fresh with /remove-lifecycle stale.

If this issue is safe to close now please do so with /close.

/lifecycle stale

kcp-ci-bot commented 5 months ago

Stale issues rot after 30d of inactivity. Mark the issue as fresh with /remove-lifecycle rotten. Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

/lifecycle rotten

kcp-ci-bot commented 4 months ago

Rotten issues close after 30d of inactivity. Reopen the issue with /reopen. Mark the issue as fresh with /remove-lifecycle rotten.

/close

kcp-ci-bot commented 4 months ago

@kcp-ci-bot: Closing this issue.

In response to [this](https://github.com/kcp-dev/infra/issues/25#issuecomment-2169209142): >Rotten issues close after 30d of inactivity. >Reopen the issue with `/reopen`. >Mark the issue as fresh with `/remove-lifecycle rotten`. > >/close Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.