mungegithub: extract hardcoded list of CLA labels into configurable list

[spiffxp]

mungegithub currently looks for one of three CLA labels:

• cla: human-approved
• cla: yes
• cncf-cla: yes

a) do we still need to look for all three, or could we just use the cncf-cla label?
b) if not, would it be worth passing in the labels as a configurable list instead of hardcodes?

[spiffxp]

@kubernetes/sig-contributor-experience-misc

[cblecker]

The cla one is the old google bot which I think can go.

The human approved one.. I'm not quite sure what the use case would be for that, or if we permit exceptions to signing the CNCF-CLA. Nothing mentioned here about that: https://github.com/kubernetes/community/blob/master/CLA.md
cc: @sarahnovotny

Either way, it should probably be configurable.

[xiangpengzhao]

If some guys want their PR merged when they are still in the progress of signing CLA but not finished, assignees can label cla: human-approved for them.

But this might lead to the PR has both cla: human-approved and cncf-cla: yes finally.

See:
kubernetes/kubernetes#41196 (comment)

[xiangpengzhao]

What if the author fails to sign CLA but the PR is merged with cla: human-approved finally?

[xiangpengzhao]

do we still need to look for all three, or could we just use the cncf-cla label?

IMO, at least, we shouldn't look for cla: yes as it's no longer used. I'm curious about that can a PR be merged if the author only signs old cla but not cncf-cla?

	// Must pass CLA checks
	if gateCLA {
		if !obj.HasLabel(claYesLabel) && !obj.HasLabel(claHumanLabel) && !obj.HasLabel(cncfClaYesLabel) {
			sq.SetMergeStatus(obj, noCLA)
			return false
		}
	}

[foxish]

/cc @yutongz
Is the old CLA label still relevant for you guys?

[yutongz]

We are not in cncf right now, so still need old one. I agree we can make it configurable. TBH, I like "human-approved" as a hacker to get cla done quickly.

[sarahnovotny]

@yutongz, can you elaborate? being "in the CNCF" is not a requirement of signing the CNCF CLA. We need to standardize on tooling and the CNCF CLA or we run legal risks with contributions.

[foxish]

@sarahnovotny, Yutong works on Istio that's also using mungegithub, not K8s. The manual override label is still useful I think. Maybe what we need is parameterization here as well, to allow different bots to respect different sets of labels.

[spiffxp]

Making the set of labels configurable and not hardcoded seems like the path forward then.

@sarahnovotny re: legal risks, does this mean we should pull support for the cla: human-approved label? PR's that have cla: human-approved but not cncf-cla: yes looked to be not a thing for nearly a year, although we've merged two in the last month

pinging @eparis to ask what happened with kubernetes/kubernetes#49447

[fejta-bot]

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.

Prevent issues from auto-closing with an /lifecycle frozen comment.

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

[cblecker]

With mungegithub on the way out and tide being the way of the future, I don't think this is relevant anymore. Would you agree, @spiffxp?

[spiffxp]

/close
I guess we can close this. I'm guessing we'll want some way of telling a user how to acquire the needed labels, in the same way that submit-queue occasionally updates its status with specific next steps. But that's orthogonal