EasyCLA Feedback & Issues

[mrbobbytables]

This issue will be used to collect feedback and issues encountered by the Community during the EasyCLA rollout.

Please post issues encountered here with as much supporting information as possible (screenshots etc).

---

/area github-integration

[MadhavJivrajani]

/cc @anusha94
fyi since you were working on adding support to the cla plugin in prow :)

[uablrek]

I have a signed CLA since 2018 (I think), now I get;

[reylejano]

This came up on the k/website Official 1.23 Release Docs PR we use to merge PRs from the k/website dev-1.23 branch into k/website main

[Huang-Wei]

I've signed CLA since mid-2018, but got this error on EasyCLA today:

kubernetes-sigs/scheduler-plugins#290 (comment)

---

Updated: My company's CLA approver approved my easyCLA request, and the above CR shows green. However, another PR doesn't, even I tried the "Not Covered" button for a few times.

[olemarkus]

I am covered by a corporate CLA, but I am getting this error kubernetes/kops#12743 (comment)

[wangchen615]

I am also covered by a corporate CLA, but I am getting this error for kubernetes/autoscaler#4131 (comment)

[dims]

one more kubernetes/kubernetes#106436

[bradtopol]

@mrbobbytables It appears there was no automatic migration of existing folks who had approval. I am having to manually add each person to the new easyCLA access list. For all IBM employees that are running into this issue please contact me on our internal slack and I will add you to the easyCLA.
@mrbobbytables if there is an easier way for me to handle this please let me know. Thanks!

[mrbobbytables]

@bradtopol For now, don't worry about adding them 1-by-1, its non-blocking and they can ignore it til the issues are sorted out.

[dims]

@pranab-bajpai is there working going on to fix this? I'd like to follow along, looks like slack channel is totally silent and no updates from the easycla team on this issue either. Could we please work in the open?

cc @caniszczyk

[bradtopol]

@bradtopol For now, don't worry about adding them 1-by-1, its non-blocking and they can ignore it til the issues are sorted out.

Really? Folks keep telling me its blocking their PRs.

[mrbobbytables]

@bradtopol yup. It's been rolled out in non-blocking mode. The old CLA is still the source of truth. If they have the label cncf-cla: yes it'll merge.

[sftim]

kubernetes/website#30504 (comment) suggests a mismatch between the new and old bots.

[dumb0002]

I am also covered by a corporate CLA, but I am getting this error: kubernetes/perf-tests#1935

[aravindhp]

I am also running into this: kubernetes/kubernetes#96120 (comment)

[MikeSpreitzer]

I also was confused by this. I did not test whether it is blocking, @bradtopol migrated me.

@dumb0002 : FYI, I see the cncf CLA is green checked on your PR.

[dumb0002]

@MikeSpreitzer: yes, as long as we have the cncf-cla: yes label we are good to go. But still I am reporting it here as suggested by @bradtopol

[mrbobbytables]

Yes, any instance where we a discrepancy between the two CLA systems should be logged. 👍

[idvoretskyi]

/cc

[sftim]

#3101 (comment) gets it wrong, I do have a corporate CLA sign off.
Do I need to authorize the bot to access my account? It seems like that's something I can click on, not sure whether it's intended.

[mrbobbytables]

@sftim the new cla is a github app and will require authorization. However it should have synced for you. Don't worry about signing it till that issue is sorted out.

[jimangel]

Feedback on behavior:

I opened a PR in k/website against the dev-1.23 branch. I later changed it to main in the GH GUI and it pulled in a bunch of unwanted commits (as expected). In the GUI, I swapped the PR back to dev-1.23 and rebased my local branch (CLI) against main and force pushed it to allow me to move branches in the GH GUI without baggage. EasyCLA proceeded to flag the delta # of users with a giant comment "blocking" (I know it's not) before I could update the GH GUI base branch.

kubernetes/website#30502 (comment)

I think this could have all been avoided if I swapped the base branch in the GH GUI first, THEN force pushed the commits (re-triggering an EasyCLA check). I'm assuming (hoping? guessing?) my next force push will resolve it.

[sftim]

I think this could have all been avoided if I swapped the base branch in the GH GUI first, THEN force pushed the commits (re-triggering an EasyCLA check). I'm assuming (hoping? guessing?) my next force push will resolve it.

@jimangel either order would have triggered similar behavior here I'm afraid. Changing the base branch first would have triggered CLA checks for all commits not shared between the two merge bases.

[sftim]

What I'd like GitHub to let you do: change the merge base during a forced push using a Git push option (GitLab has features for this, I don't think GitHub does). IMO that's more an issue with atomically changing the merge base during a forced push and less about EasyCLA.

[jimangel]

@jimangel either order would have triggered similar behavior here I'm afraid.

I could have been lucky with timing, but I did update the base branch (saw all the commits appear in the GH GUI) and reverted back, which didn't trigger EasyCLA.

First time:

Second time:

The difference being a force push the second time that included commits not in dev-1.23 because my origin branch was rebased against main before I could toggle the PR target branch in the GUI.

I don't know for sure, but I'm guessing EasyCLA triggers on push events vs. GH UI actions (like switching base branches)?

[reylejano]

We had more that came up in a PR to sync the dev-1.23 branch with updates from main in k/website

[ykakarap]

I have previously signed the old CLA and have been contributing for the ClusterAPI project for a while but now I am getting the following error.

[Shubham82]

Hi folks,
I am also facing an EasyCLA check failure in this PR kubernetes/website#30430
even /easycla comment is also not working in my case. please suggest any workaround for it.

[adisky]

I have previously signed CLA but Easy CLA is failing for me, I have also tried to sign it but it is redirecting to mail id that no longer exist in my github account

kubernetes/kubernetes#106449

[killianmuldoon]

I signed the old CLA in 2019, and signed again when EasyCLA came out. EasyCLA is now failing again (between commits) on this PR: kubernetes-sigs/cluster-api#5735

[waltforme]

Same issue with EasyLCA on my PR:

[sftim]

EasyCLA didn't like my squash-and-forced-push: kubernetes/website#29685 (comment)

[uablrek]

Is there a simple way of checking my own CLA status (both)? A button or form perhaps?
I mean not by creating a fake PR.

[Prajyot-Parab]

I am covered by a corporate CLA, but I am getting this error for kubernetes-sigs/cluster-api/pull/5806

[pranab-bajpai]

Hi All,
Wanted to thank you for posting issues as we work through the issues with EasyCLA.
We are going to do weekly DB migration from current Kubernetes CLA to latest EasyCLA DB. Recent migration was completed on 12/7, another one will be completed by 12/9. We are hoping that most of the user mismatch issues should stabilize with latest migration on 12/9. We plan on keeping an eye on the issues reported on this thread and will work with you all to deploy EasyCLA only when Kubernetes community is comfortable.

Thanks,
-Pranab
(Product Manager EasyCLA)

[pranab-bajpai]

Is there a simple way of checking my own CLA status (both)? A button or form perhaps? I mean not by creating a fake PR.

Only Project Managers can see if a user has signed CLA or not in the Project Control Center admin view of EasyCLA V2. There is no way for an individual to check without creating a PR.

[uablrek]

Still problems: kubernetes/kubernetes#97081 (comment)

[uablrek]

It works! kubernetes/kubernetes#107027 (comment)

I permit access and requested acceptance for company CLA for "Nordix". I don't know if anybody did something or if the request/permit was enough. Anyway, I am good. Thanks 👍

[aznashwan]

Hello Everyone,

I have this PR on kubernetes-sigs/cri-tools where I believe the CLA (re)checking does not work properly.

I had indeed initially submitted the PR without the CLA, but I'm 99% sure me/my management have followed the correct steps for my PR to be accepted afterwards (we contribute to CNCF projects regularly so we're used to the process but I cannot completely rule out a mistake on our end)

Are there any recommended debugging steps which come to mind which might help identify/fix the issue?

[Shubham82]

Hi folks!
I am still getting EasyCLA check failure in my every PR. The latest one is kubernetes/kubernetes#107744 (comment)

Please take a look!

[mrbobbytables]

We will close the feedback thread on March 5th, that will have been 1 month post-cut over. 👍

[RA489]

We will close the feedback thread on March 5th, that will have been 1 month post-cut over. 👍

+1. Thanks for driving this effort.

[MikeSpreitzer]

Is there a TL;DR here? What does someone who is getting false CLA failures do?

[mrbobbytables]

@MikeSpreitzer we as a project cannot do much, its pretty much follow the link the EasyCLA bot response to log a ticket with the LF. =/

[mrbobbytables]

Going to go ahead and close this out. Future issues can be created ad-hoc.

/close

[k8s-ci-robot]

@mrbobbytables: Closing this issue.

In response to this:

Going to go ahead and close this out. Future issues can be created ad-hoc.

/close

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.