PR auto merge policy

[rootfs]

Is your feature request related to a problem? Please describe. Set up role based auto merge.

Currently we have assigned roles. The CI can take this info and auto merge PRs

Describe the solution you'd like

• The PRs should be labeled with the area of expertise.
• Small changes can be auto merged can happen with 2+ reviewers approval or 1+ maintainers approval
• Significant changes can be auto merged can happen with 3+ approvals, any combinations of reviewers and maintainers

[marceloamaral]

Maybe 3+ approvals is too much

I would suggest, the PR must have a lgmt label and 1 approval Both the reviewers and maintainers can approve but only a maintainer can add the lgmt label

[rootfs]

Maybe 3+ approvals is too much

I would suggest, the PR must have a lgmt label and 1 approval Both the reviewers and maintainers can approve but only a maintainer can add the lgmt label

lgtm :D

[SamYuan1990]

hi @marceloamaral and @rootfs do you have any github action for sample, so far I found one as https://github.com/pascalgn/automerge-action

• MERGE_LABELS as lgmt
• MERGE_REQUIRED_APPROVALS to 1

Are there settings above good enough for us? I suppose we are using account role control as the user in list able to get approvals right?

[rootfs]

@sallyom has some ideas

[sallyom]

can opt-in to auto-merge and much more by plugging into github.com/openshift/release CI platform (doesn't have to be specific to openshift - can configure things like lgtm/approvals/etc and can set some checks as optional/non-blocking) I'm looking at adding a test to verify the manifests/openshift - that check would stay optional but can configure the others to block merges (make format, make golint, make test) here's a very rough WIP: https://github.com/openshift/release/pull/32639 oh! looks like gofmt is passing so that's a start!

[SamYuan1990]

can opt-in to auto-merge and much more by plugging into github.com/openshift/release CI platform (doesn't have to be specific to openshift - can configure things like lgtm/approvals/etc and can set some checks as optional/non-blocking) I'm looking at adding a test to verify the manifests/openshift - that check would stay optional but can configure the others to block merges (make format, make golint, make test) here's a very rough WIP: openshift/release#32639 oh! looks like gofmt is passing so that's a start!

wait a min, we are using github action but not OpenShift CI, are we need to follow https://docs.ci.openshift.org/docs/how-tos/contributing-openshift-release/ ?

[sallyom]

@rootfs @marceloamaral to setup with openshift/release, an OWNERS file is required. This ensures that only those listed can approve modifications to the test configurations. Here's an example: https://github.com/backube/volsync/blob/main/OWNERS (note that volsync is also not in the openshift org - they use openshift/release CI because they also want to periodically ensure that volsync can run successfully on OpenShift, and this repo also takes advantage of the openshift CI features)

[sallyom]

@SamYuan1990 above I shared volsync - that is a repo that is not part of the openshift org- they use the openshift CI in addition to GH actions. See this PR as an example: https://github.com/backube/volsync/pull/439

[SamYuan1990]

ok I see, so are we going to moving to/addition with OpenShift CI? btw, if we addition with OpenShift CI will we have OpenShift cluster to deploy with?

[sallyom]

ok I see, so are we going to moving to/addition with OpenShift CI? btw, if we addition with OpenShift CI will we have OpenShift cluster to deploy with?

sort of once the test is configured, if/when in a PR you comment something like /test e2e-openshift that will trigger an OpenShift ephemeral cluster to be deployed, and in that cluster kepler will be deployed and verified (for example, could add a script to confirm all pods healthy, dashboard up, non-zero values, etc) - once that verification test is complete the cluster is torn down - so that cluster will only be around for the time it takes to run the verification test. If desired, the test can be triggered with every PR/update but for now it will be an optional test & manually triggered w/ the GH comment. Or, could instead schedule a periodic check on OpenShift that will not be tied to PRs. Either way, it'll be a short-lived cluster for only this check.

[marceloamaral]

I am ok with all directions.

But why don't we start to the simple one and extend it to the more complex one later?

[rootfs]

FYI, i just created teams. CI can tag the teams to assign/review/merge issues and PR

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.