CLA check failing on new PR

General JUCE discussion
1

Hi,

I just signed the CLA, and created a PR to the JUCE repo, but the CLA check on my PR is failing; the reason given is ‘unsigned’:

'verification': {'verified': False, 'reason': 'unsigned', 'signature': None, 'payload': None, 'verified_at': None}

I should note that the commit email used in my git commits is not the same as the one used to sign the CLA (because I don’t want that one to be in the public record), but I’m not sure if that’s the reason that this is failing. Are there additional steps beyond signing the CLA that I need to take in order to create PRs?

Thanks

2

The reason is printed a bit further up:

No author or committer user IDs contained within commit information

It looks like you have signed the CLA OK, but the data returned by the GitHub API has null for both the author and committer.

We need to see newspacer listed as the author or committer for everything to line up.

3

Thanks for your reply.

Looking at the rest of the response from the Github API, I can see that both the author and committer clearly are populated. I had a look at the code used in the workflow file for the CLA check, and it looks like it’s checking in the wrong place for the author/committer info; the line:

allAuthors = [commit[authorType]['login'] for authorType in ['author', 'committer'] for commit in prCommits if commit[authorType]]

doesn’t match the schema returned from the Github API. If I change it to:

allAuthors = [commit['commit'][authorType]['name'] for authorType in ['author', 'committer'] for commit in prCommits if commit['commit'][authorType]]

i.e. it should be looking in commit['commit'], and under the field name not login. After making this change and running the script locally using the relevant URL for my PR (https://api.github.com/repos/juce-framework/JUCE/pulls/1479/commits), it succeeds for me.

This seems a bit strange though: I can’t believe there was a change to the Github API and I’m the first to notice it? Or maybe this CLA verification job just doesn’t get run very often?

Thanks.

4

Here’s a page of passing checks: Pull requests · juce-framework/JUCE · GitHub

We want to use “login” rather than “name” so there’s a clearer link to the GitHub account that made the change. The name field is much more ambiguous.

Something about how you put your commits together is unusual, but I don’t have any solid ideas what that might be.

5

I didn’t do anything other than setting the user and email locally with

$ git config user.name ...
$ git config user.email ...

and then pushed via ssh. I don’t use the github CLI, or GPG key signing, for example; is something like that required?

Unfortunately the page on the Github API doesn’t contain any info on how to populate these fields.

6

Looking through the link Tom supplied I can see that commits from others show in the commit details as <some user> committed <date/time of commit> whereas your commit says Signed-off-by: newspacer <youremail>. Are you using --signoff when committing (Git - git-commit Documentation)? Not sure why that would cause issues mind. I take it that the email in the commit is also attached to your GitHub account? If not you should be able to add it from GitHub by clicking your profile picture in the top-right, go to Settings, them Emails (on the left).

7

Thanks for the feedback. The signoff was something I tried when the CLA check failed initially, pretty sure it’s not relevant (and it didn’t help anyway).

For now I have just submitted the change via GH’s web UI; it’s a small change so that’s not a problem for now, and that seems to have provided the extra auth steps needed for the CLA check to pass, so for this PR it’s at least solved.

I still have no idea why it’s not working from a ‘normal’ git push though, and can’t find anything about it on GH’s REST API documentation. There must be some extra authentication step that I’m missing.

EDIT: It does seem to have been the commit email that was the cause of this, thanks for the pointer. So the email specified in git config user.email has to match what is configured in the github account. GH has a feature to mask this email, but it’s not on by default :hot_face: so if anyone doesn’t want to make their email public, that should be enabled; GH then gives a substitute masked email address which can be used in git config user.email, after which author and committer are populated in the REST API calls.

GH docs

2 Likes
8

Thank you for working it out, and sharing your findings.

I’m a bit surprised we haven’t run into that before. I’ll add a suggestion to the error message if we don’t find the info we need in the API response.

9

Also a note in the contribution guidelines would be helpful IMO.