Now that bugs.python.org 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.
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.)
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.)
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.
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.
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?
Yes but he signed the CLA using his @gmail.com 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.
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.
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.
