Https:// is now using a new CLA bot

Now that is in read-only mode, we needed to move away from the-knights-who-say-ni to a different solution. In the end, we’re using a customized version of the EdgeDB CLA Bot. The modified code lives under ambv/cla-bot for now, I’ll be moving it to the Python org next week.

Please report any issues with the new workflow to me.

The main differences between the old workflow and the new one are:

  • as an individual, you can now sign a CLA right in Github with instant effect;
  • the CLA check is a regular Github check;
  • the bot comments on the issue and does not use labels.

As before, the bot is only enabled for select repositories in the python organization on Github. If you see it missing anywhere, let me know and I’ll add it.



Once the CLA is signed, the bot edits the comment and the status gets updated:


Just to be clear, our CLA signing status has been ported over, right? I.e. we won’t have to resign the CLA will we?

Yes, all information was ported over from BPO to the new CLA host. If anything, this new one should be more robust as it includes all e-mails on the Github account, not only the main one.


I just used blurb_it to add a news entry to PR 30808, and the bot added a “CLA not signed” comment although I did sign it. Is this something that you can fix or should I report this on the blurb_it repo?

(As a feature request: It would be helpful if the CLA bot showed which of multiple commit authors haven’t signed the CLA.)

I’ll fix that. Thanks for reporting.


We’re seeing a similar issue on PR #90153; see John’s comment here. (Just reporting for the record in case it helps with diagnosis and fix; there’s no action needed for that particular PR, since it looks as though the CLA check is not yet a required check.)


There were a few issues that I addressed today.

Private e-mails on GitHub

GitHub allows you to hide your email when performing actions with the GitHub UI:

This can trigger an email change on your existing PR when you click “Update branch” to rebase it. In this case the CLA check would fail to find the pseudo-email and force you to sign the CLA again needlessly. This is now fixed: if you signed the CLA previously, GitHub pseudo-emails will be honored as well.

Excluding bot accounts from CLA checks

We have some bots generating commits, like blurb_it. They were triggering CLA checks which obviously failed. They no longer do.

Other changes pending

There’s a few other things I’ll be addressing tomorrow like clearer messaging by the bot, some rare bot interactions, and ability for users to check if a CLA was signed via a Web form.


The CLA Signing check is currently not required, which is a regression. Should we make it into required checks?


I’m on it.


Bug: There appears to be no discoverable way to get the CLA bot to re-evaluate a PR. See what I tried on gh-89455: Fix an uninitialized bool in exception print context. by gpshead · Pull Request #91466 · python/cpython · GitHub. After fixing up my commits to have an acceptable email address and pushing a new commit, force pushing those, adding a new commit, closing and reopening - it never did anything and is stuck thinking the old email address still applies.


The bug is that it doesn’t remove emails from its cache that it already parsed in previous runs for a given PR. I’m looking into it.


Ahha, I suspected something like that. Either in its DB or encoded in the base64 string in the giant URL behind the status message button it left on the PR.

A “force push” event is unusual on a PR but assuming github allows it to detect that (it’s in their UI so I’m assuming they expose it as an API event?), it is a good indicator that it needs to re-process all commits.

I don’t mind having to push a manual “reprocess the PR” button of some form after a force push given how infrequent those are. In absence of anything else, I expected closing and reopening to be such a trigger based on other bot experience.

1 Like

I just added a merge-commit to my pre-migration-PR and suddenly it complained I didn’t sign the CLA.
Even though the PR still has the CLA signed label:

I clicked the link, signed in with GitHub, but then was just redirected back to my PR without anything changing.

After that I forced pushed, but based on the comments above here I should do a “regular” commit to trigger it again?

We no longer use labels for CLAs. You signed your CLA alright, @Safihre but there is no CLA signed for the other author’s josh@code… email.

1 Like

He has signed the CLA, see his other PR that this one is based on:

Yes but he signed the CLA using his address while the commits in the PR are made from a @code... domain. The new CLA bot doesn’t allow for such mismatch. All he needs to do is to click through the CLA page on the PR, as you did.

Does the message from the CLA bot clearly state which email address(es) still need to sign?

It doesn’t yet but I’m working to change that.


Ok. It’s probably written somewhere, but that’s not very obvious…
I had to make my PR because he abanonded his original one. So doubt he’ll come back to sign. Will have to work around that.
But that’s off-topic for this thread.
Thanks for clearing it up.

The CLA bot is not nice with me today, probably because I signed the CLA with an old email or a + or something like that?

It’s happening in Doc: Update py2app link. by JulienPalard · Pull Request #91585 · python/cpython · GitHub

But it’s a good occasion for me to check how it goes for newcomers, and I’m surprised to see the CLA bot requires those github permissions:

  • Know which resources you can access
    When authorized, the GitHub App will be able to programmatically read the private GitHub resources that you can access (such as private GitHub repositories) where an installation of the GitHub App is also present. The application may use this, for example, so that it can show you an appropriate list of repositories.
  • Act on your behalf
    The application may need to perform tasks on GitHub, as you. This might include creating an issue, or commenting on a pull request. This ability to act on your behalf is limited to the GitHub resources where both you and the GitHub App have access. In some cases, however, the application may never make any changes on your behalf.

Does someone knows why the bot needs those permissions?

I can easily imagine imagine people refusing to sign the CLA just because the permissions are too broad, the message may be perceived as: “To be allowed to contribute to Python, let us read and commit to your private repositories” (I don’t know if the app would really be able to do it, but some people will understand it as is).

Typically I would never accept any Github app requiring those permissions.