Bugzilla – Full Text Bug Listing
| Summary: | [CLA] Something wonky with CLA group membership | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Community | Reporter: | P. Ottlinger <phil> | ||||
| Component: | GitHub | Assignee: | Eclipse Webmaster <webmaster> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | blocker | ||||||
| Priority: | P3 | CC: | benjamin.grouhan, cletavernier, denis.roy, eclipse, eposse, ericwill, erleczar.mantos, gregw, guillaume.coutable, jrn, mauricio.alferez, nagavijay.sivakumar, shatilov, simon.laffoy, timvolpe, wayne.beaton, zeratul976 | ||||
| Version: | unspecified | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Linux | ||||||
| See Also: | https://github.com/eclipse/eclipse-webhook/pull/20 | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
P. Ottlinger
Bugzilla doesn't recognize your CLA status either. We'll look into this. Oddly, you were not in the CLA group, yet you signed the CLA on May 13. I've put you in there, and the PR validation has passed. Thanks - all is fine as it was a couple of days :-) CLA status is correct in bugzilla and via Github. Denis, Phil, I'm not seeing the CLA green tick next to P.Ottlinger in bugzilla... which I think I need before attempting a push with Also-by: P. Ottlinger<phil@edojo.org> Yep, I'm seeing that. I started monitoring this yesterday; something is wonky with the CLA status. *** Bug 468580 has been marked as a duplicate of this bug. *** *** Bug 468496 has been marked as a duplicate of this bug. *** *** Bug 468610 has been marked as a duplicate of this bug. *** *** Bug 468559 has been marked as a duplicate of this bug. *** *** Bug 468574 has been marked as a duplicate of this bug. *** (In reply to Denis Roy from comment #5) > Yep, I'm seeing that. I started monitoring this yesterday; something is > wonky with the CLA status. FYI, I did try my push with an Also-By and it worked fine even without the green tick, so perhaps it is just a display thing. *** Bug 468625 has been marked as a duplicate of this bug. *** The Also-By has the disadvantage of not closing the pull request properly thus leaves the impression that the request was not accepted. At the moment everything seems fine .... not sure if it's a browser issue or something within the backend. As far as I'm concerned, I still have the error message reported in Bug 468625. The CLA page says that my CLA is valid until 2016 but on Bugzilla the CLA icon near my username shows that I did not sign the CLA. This is blocking me as I'd need to submit into gerrit before RC3 code freeze. Thanks for your help. I see that some users that was missing valid CLA now got them all right. I'm not sure, if someone fixed it by hand or it fixed itself, but I'd be glad if someone could fix mine too. Just right now I've signed new CLA and it works for me. (In reply to Pawel Nowak from comment #16) > Just right now I've signed new CLA and it works for me. Did you invalidate your old one and sign again? FYI, it worked for me today with the current CLA after I noticed that the CLA icon/marker on Bugzilla was green again for me. I did not have to reset anything. (In reply to Eric Williams from comment #17) > (In reply to Pawel Nowak from comment #16) > > Just right now I've signed new CLA and it works for me. > > Did you invalidate your old one and sign again? Exactly (In reply to Pawel Nowak from comment #19) > (In reply to Eric Williams from comment #17) > > (In reply to Pawel Nowak from comment #16) > > > Just right now I've signed new CLA and it works for me. > > > > Did you invalidate your old one and sign again? > > Exactly I just did this and it worked. :) Some of the committers in our project are getting a "git-receive-pack not permitted" error when trying to push to Gerrit. Is this the same error that others are getting? (In reply to Ernesto Posse from comment #21) > Some of the committers in our project are getting a "git-receive-pack not > permitted" error when trying to push to Gerrit. Is this the same error that > others are getting? No, that error is most likely caused by committers trying to push 'directly' to the repo (URL: ssh://committer_id@git.eclipse.org/gitroot/papyrus-rt/reponame.git) instead of using the Gerrit URL (ssh://committer_id@git.eclipse.org:29418/papyrus-rt/reponame.git) -M. We've definitely discovered _why_ the CLA status is disappearing, and I'm pretty sure I have patched it. I'll give it another 24h. We've found some bad code that was removing >2000 non-committers from the CLA group every day. The code was fixed, and for the last 2 days the CLA group membership has been sane. Thanks for everyone's patience. This seems to be happening again: https://github.com/eclipse/vert.x/pull/1124 This seems to be happening again: https://github.com/eclipse/vert.x/pull/1124 *** Bug 476934 has been marked as a duplicate of this bug. *** One thing we've been seeing a lot lately are message like this, when we run the hourly committer sync: fatal: unable to access 'https://github.com/locationtech/udig-platform/': Failed connect to github.com:443; Operation now in progress fatal: unable to access 'https://github.com/locationtech/geomesa/': Failed connect to github.com:443; Operation now in progress This is for the LocationTech organization, but we see similar notices for Eclipse. As far as I know, GitHub imposes limits on the number of API calls per hour we can make. But at any given time when I check, we are nowhere near those limits. I'll start investigating from that angle, because the PR failures seem sporadic. Here's an example from the same script, running on eclipse.org servers for the Eclipse organization: fatal: unable to access 'https://github.com/eclipse/birt/': Failed connect to github.com:443; Operation now in progress fatal: unable to access 'https://github.com/eclipse/birt/': Failed connect to github.com:443; Operation now in progress fatal: unable to access 'https://github.com/eclipse/birt/': Failed connect to github.com:443; Operation now in progress fatal: unable to access 'http://github.com/eclipse/birt/': Failed connect to github.com:80; Operation now in progress From http://github.com/eclipse/xtext 1dbe47c..86ac8f9 -> so_generator_improvements From http://github.com/eclipse/xtext 1dbe47c..86ac8f9 -> sz/bug467960 From http://github.com/eclipse/xtext - [tag update] -> Galileo_M5 ... the rest succeeds. Is there any workaround for this? I can't do a pull request to our repo. Hi Guys, any progress on this front? Erle, you're correctly identified as a having a valid CLA(you have the tag here in bugzilla) and I've verified that by checking the group membership. Taking a quick look at: https://github.com/eclipse/vorto/pull/29 it looks like only some for your changes have failed validation, and the validation error implies that there is an error in the 'signed off by' footer. Can you confirm that? -M. Created attachment 257247 [details]
Two commits, same signoff, one passed validation, one doesn't
That's the problem. All of my commits are using the same signoff (created using --signoff in git) and yet some passed and some don't. I attached a screenshot above showing two commits using the same signoff and yet one somehow managed to passed validation but the other one doesn't. GitHub Pull Request 20 created by [eclipsewebmaster] https://github.com/eclipse/eclipse-webhook/pull/20 From: genie@eclipse.org Subject: [Bug 468552] @id = 468552 @see_also = https://github.com/eclipse/eclipse-webhook/pull/20 GitHub Pull Request 20 created by [eclipsewebmaster] https://github.com/eclipse/eclipse-webhook/pull/20 (In reply to Erle Czar Mantos from comment #34) > That's the problem. All of my commits are using the same signoff (created > using --signoff in git) and yet some passed and some don't. I attached a > screenshot above showing two commits using the same signoff and yet one > somehow managed to passed validation but the other one doesn't. Can you link to the actual pull requests? I can replay the Github payload that is sent to our servers. (In reply to Denis Roy from comment #36) > (In reply to Erle Czar Mantos from comment #34) > > That's the problem. All of my commits are using the same signoff (created > > using --signoff in git) and yet some passed and some don't. I attached a > > screenshot above showing two commits using the same signoff and yet one > > somehow managed to passed validation but the other one doesn't. > > Can you link to the actual pull requests? I can replay the Github payload > that is sent to our servers. Dennis, I am getting IP Validation error. (ip-validation — The pull request did not pass Eclipse validation. ). https://github.com/eclipse/vorto/pull/44#partial-pull-merging I belong to same team as that of Erle Czar Mantos. I have signed CLA already. Please let me know if there is any step that I need to do from my side. If not, can you please help me to resolve this issue. Regards Nagavijay Sivakumar (In reply to Nagavijay Sivakumar from comment #37) > Dennis, > I am getting IP Validation error. (ip-validation — The pull request did not > pass Eclipse validation. ). > https://github.com/eclipse/vorto/pull/44#partial-pull-merging > > I belong to same team as that of Erle Czar Mantos. I have signed CLA > already. Please let me know if there is any step that I need to do from my > side. If not, can you please help me to resolve this issue. I don't know if the CLA is a red herring -- the check is also complaining about the missing signed-off-by directives. The last comment on the PR is: Hi Vijay, please squash your commit with merge --squash and then sign off only that single commit with commit -s Cheers ,Alex Have you done that? Pushing a merged commit with the signed-off-by should yield success. *** Bug 489687 has been marked as a duplicate of this bug. *** I just nailed a very nasty bug with the CLA check. Essentially, each PR with more than one commit from two different contributors was failing. GitHub Pull Request 23 created by [eclipsewebmaster] https://github.com/eclipse/eclipse-webhook/pull/23 [reply] [−] Comment 10 Denis Roy CLA Friend 2016-03-16 14:34:33 EDT Nailed it! This was a long standing bug behind bug 468552. Essentially, our LDAP client was losing its resource link after one search... so multiple commits in a PR were all susceptible to this. PR #107 now passes the validation. |