The CLA bot is dead, long live the CLA bot!

And it is written in Python :slight_smile:!

Over the last week, I worked with @ambv to replace our difficult to maintain and expensive to operate typescript/edgedb cpython-clabot Heroku app with a new async Django/Python/gidgethub/Postgres clabot running on the PSF community infrastructure.

The primary driver here was to reduce the cost of operation, but this also sets us up to develop the bot, and provides some immediate improvements like showing the installed repositories, and you can now sign in to https://cla.python.org to view all agreements previously signed which are associated with your GitHub username.

The bot is live now. All agreements and signatures have been migrated from cpython-clabot, the pre-approvals for bots have been accounted for, the state has been synced and all open PRs have been updated. (There was a small mis-fire that posted a comment on the 49 most recent pull requests that it shouldn’t have, sorry :frowning: )

If a new repository needs to have CLA signing enabled, you can ask me or @ambv or one of the python GitHub Organization owners to add the repository to the installation. CLA signing will then be enforced, and a backfill task can be run to check/update existing Pull Requests.

The experience is designed to be equivalent to the existing bot, setting a commit status, only commenting if a CLA needs signed, and updating existing comments when a signature is completed.

I’d love some contributions, particularly from folks experienced with unit-testing GitHub/gidgethub integrations, as it is only currently manually tested :upside_down_face:.

31 Likes

Because gidgethub is sans-I/O by design, you could use a dummy class at the bottom to replay payloads to make sure you can handle the responses as expected. Otherwise does the network library you’re using have a playback mechanism? Or I guess mock it out as necessary?