Test-infra: Setup merge automation for all kubernetes repos

Created on 10 Jan 2018 · 18Comments · Source: kubernetes/test-infra

/assign
/area prow
/sig contributor-experience
I've been doing this organically, here's an umbrella issue to keep track

The general process I've been following lately is:

File an issue with these steps
Create/update an OWNERS_ALIAS file that names the existing teams that have write/admin access to the repo
Create/update an OWNERS file with approvers based on the write/admin access teams
Configure prow to turn on the "approval" plugin for this repo
Configure prow/tide to include this repo in the tide query
Hold off if there are any objections or special cases

Issues used to add repos in the past:

https://github.com/kubernetes/website/issues/6906
https://github.com/kubernetes/sig-release/issues/44
https://github.com/kubernetes/kube-deploy/issues/480
https://github.com/kubernetes/ingress-nginx/issues/1895
https://github.com/helm/helm/issues/3333 (did not proceed)

- https://github.com/kubernetes/dashboard/issues/2747

EDIT: as of 2018-09-17

[1] - staging repos live in kubernetes/kubernetes/staging and so use whatever merge automation kuberentes/kubernetes has

areprow lifecyclfrozen sicontributor-experience

Source

spiffxp

🎉1

Most helpful comment

/remove-lifecycle rotten

cblecker on 29 May 2018

😄1 👍1

All 18 comments

Why should all the repos have or use merge automation? What's the benefit for those that aren't using it today?

mattfarina on 11 Jan 2018

Why should all the repos have or use merge automation?

@mattfarina this was a conclusion that the steering committee reached when trying to define what constituted Kubernetes repos. Not sure if that doc got sent to the dev list, but here is a link: https://docs.google.com/document/d/1yauW9zMtWgXN8xh4q6144B2xBTPuIOLGc0L6aQPMj1I/edit?usp=sharing

stevekuznetsov on 11 Jan 2018

Benefit is a consistent experience between repos, which makes it easier to move around between them efficiently.

fejta on 11 Jan 2018

The other benefit is that it means that all repos can be included in the general release process where required. Realistically, the release team cannot manage or even monitor repos which use a completely different workflow and labels from everything else. Now, some sub-projects will never have this concern, but a lot will.

jberkus on 11 Jan 2018

@jberkus why would everything use the general release process? For example, there is talk of moving kubectl out of k8s and having an independent release process and timing from k8s. It would decouple them. What benefit would kubectl have to use the general release process meant for something different?

@fejta Three things come up for consistency.

We have issues with contributor experience. If we have a consistent experience that's hard that won't help.
How many people move from repo to repo? How much moving around is there? Is it a core group of people or most people? Have we looked at how much of a deal that is? Without knowing that how can we prioritize it.
Consistency doesn't allow for innovation. If everyone needs to use the same tooling how can someone go innovate a better way to do something? The first mover wins. Look at Netflix. They don't enforce tools. Instead it's self service. Someone can go their own route and those someones become the new self-service options.

@stevekuznetsov As I understand it, the tooling parts were added after the steering committee reached conclusions in that doc. That was an addition after the fact.

In any case, because some group concluded it is not a good justification. People should be able to answer my original questions in a positive way for people.

And, we should be able to go back and audit the conclusions and reasons for what the steering committee went with later. Things change and those things may not apply later.

mattfarina on 11 Jan 2018

@mattfarina if the release process is completely decoupled and the subproject isn't interested in using the same release tools, then of course that doesn't apply. However, right now we have the opposite: several repos who do participate in the general release process but not with the same labelling or automation. That's why I'm saying that those two things need to be tied together.

jberkus on 12 Jan 2018

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

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

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

fejta-bot on 24 Apr 2018

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.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten
/remove-lifecycle stale

fejta-bot on 24 May 2018

/remove-lifecycle stale

On Thu, May 24, 2018 at 2:41 PM fejta-bot notifications@github.com wrote:

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.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta
https://github.com/fejta.
/lifecycle rotten
/remove-lifecycle stale

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes/test-infra/issues/6227#issuecomment-391872471,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA4Bq6XQG37-ApCP4h0a441x5t3JJQRfks5t1yjzgaJpZM4RZ0xn
.

BenTheElder on 25 May 2018

😕1

/remove-lifecycle rotten

cblecker on 29 May 2018

😄1 👍1

thanks @cblecker. for anyone following along, @spiffxp is still on this but is on extended OOO. I imagine he'll continue this when he gets back

BenTheElder on 29 May 2018

/lifecycle frozen
Yeah I'll update this at some point, need to include all repos across all orgs.

spiffxp on 14 Aug 2018

Related, I'm making sure all repos have OWNERS files, which sets the stage for them to use /approve (and thus tide) https://github.com/kubernetes/community/issues/1721

spiffxp on 14 Aug 2018

Related, I'm making sure all repos live inside of sigs.yaml in one for or another. I anticipate this can help us head towards a sig-driven peribolos config https://github.com/kubernetes/community/issues/2464

spiffxp on 14 Aug 2018

tide doesn't require /approve FWIW, do all repos need it?

stevekuznetsov on 14 Aug 2018

True, I guess the reason I use it as a precondition is that any org member can /lgtm, while the use of /approve ensures there aren't drive-by merges

spiffxp on 14 Aug 2018

👍1

/close
This is now done

spiffxp on 18 Oct 2018

@spiffxp: Closing this issue.

In response to this:

/close
This is now done

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 on 18 Oct 2018

Was this page helpful?

0 / 5 - 0 ratings

Related issues

Pod (Utilities) racing

cjwagner · 3Comments

trusted_org not working in trigger

BenTheElder · 4Comments

prow/blunderbuss: possibly use UserStatus?

cblecker · 4Comments

Label plugin parsing problem ("The label(s) kind/ cannot be applied")

benmoss · 3Comments

Interval-based Periodic Jobs Triggered Constantly

stevekuznetsov · 4Comments