PR Processor Next Generation

Development
1

Hello everyone,

Some of you may have already seen this, but I’ve started to rewrite the PR processor into a Github application. An example probably says a lot more than a bunch of text:

image
image1597×1103 82.8 KB

Currently only Redmine issue checks are implemented, but the reporting is much better. Rather than comments inside the main thread, it now uses the Checks tab to report on issues. It’s live on foreman, smart-proxy, foreman-installer, foreman-selinux and foreman-packaging now to evaluate how it performs.

When it all works well, I’m going to enable it on all theforeman repositories and allow the bot to run on any organization so it can be used on Katello as well. This is trivial from the Github side, but I need to implement limits. If desired, we can probably also make it work for Pulp and their (branded) Redmine instance. Once that’s done, I’m going to drop the comments from the classical bot.

Future work

We’ve had a discussion about improving PR merge velocity and various items from that thread can be implemented.

I’d like to remove code owners and replace it by intelligent bot checks that request the packaging team to review it. Ideally we’d kick off a packaging scratch build and do a repoclosure check but that’s more long term.

Technical details

The current PR processor is a Sinatra application that runs as a regular user using webhooks. The benefits of an are are access to the checks API and removing the need for a separate account. It also means we can simply enable it on all repositories without manual configuration everywhere.

For the next generation I chose Python as a basis. This is mostly because I was talking to an Ansible developer and he maintains octomachinery which makes writing a GH app easy. It’s also because I’m selfish and writing Python is much easier for me. The sources are in the app branch of the PR processor git repository.

5 Likes
2

Looks good! My question, that I asked in person as well, is can we reduce our maintenance overhead and implement these checks as Jenkins jobs or as stages in PR tests themselves?

3

Maybe, but a big benefit is using the checks API which gives us the tab inside the PR. That’s only allowed for Github Apps, not the regular API. We can use GitHub - webknjaz/check-in: Checks your test results metadata into github, commit-bound. Acts as a bot. You'll need a GitHub App to use it. but it relies on Python 3.6 which we currently can’t use on our CI. This was much easier to implement.

I’ve subscribed to the Github Actions beta as well. That will allow us to run the checks inside the GH infrastructure (using containers). The framework it’s built on should allow using this as well. Not sure if that makes sense for us, but I’d at least like to have a look.

4

I can add that I was having an idea of having a “CI mediator” app which would’ve work as a GitHub App and also receive statuses from real CIs acting as a proxy (more or less).
I didn’t get to actually implementing that, though.
The problem with check-in is that you’d need to have a check-run ID global for all jobs in build and I’m not sure how easy is to implement that on top of the pure CI.

5

I was also thinking about the “CI mediator” that summarizes different inputs. Ideally giving contributors and reviewers clear steps of how to move a PR forward. A lot of bots place comments, but IMHO that mostly distracts from human communication. A check could be a nice place for the most up to date instructions. Other than a general idea I have nothing concrete though.

6

Yeah, that’s what I was thinking. It’s been on my todo list for a while. Dunno when I get to implementing it…