Update on r-rmcgibbo bot: automatic nixpkgs-review

In a previous post, I announced the first iteration of the “r-rmcgibbo” bot, which runs nixpkgs-review against a large proportion of PRs to nixpkgs.

I wanted to give a short update.

The bot has been running (mostly continuously) over the last month. I have been making some updates to its code base and methodology, and I think it’s starting to stabilize. According to my logs, it’s been run on about 4,500 nixpkgs PRs for x86_64-linux and 4,200 nixpkgs PRs for aarch64-linux.

As currently configured, it runs a fork (many of the changes are described here) of nixpkgs-review that adds a few features, and runs nixpkgs-hammering to provide “suggestions”.

Although the vanilla version of nixpkgs-review tries to build every changed nixpkgs attribute in a PR, you might have noticed that the r-rmcgibbo bot sometimes says that it skipped certain attrs because of “time constraints”. This is based on a calculation that tries to find a subset of the modified build graph that can be built within a cutoff (currently set at 1.5 hours) based on build time estimates for each package that were determined based on hydra’s logs, and are now being refined based on r-rmcgibbo’s own logs. With this feature, the r-rmcgibbo bot can be run against PRs to all branches, including staging. (However, sometimes the staging jobs on hydra have are sufficiently backed up that building any staging package requires re-building stdenv, in which case the build is usually predicted to take longer than 1.5 hours and is skipped.)

The bot runs on AWS infrastructure. It has a front-end process that watches Github for new PRs and a back-end that builds PRs, connected via a queue. The backends run on fairly small machine types. These machines are not always capable of building every PR; the bot is programmed to detect OOMs, timeouts, and disk-full scenarios, and cancels its github comments when such an event is detected. All in, the cost to operate it is ~$40-50 USD / month.

My priorities going forward are:

  1. Open-source all of the code (auditing to make sure I haven’t left my AWS credentials in there anywhere, right now the code and the AWS infrastructure are a bit too intertwined).
  2. Upstream the appropriate features from my fork into Mic92’s nixpkgs-review itself.
  3. Discuss with nixpkgs stakeholders if and how this idea could be moved into OfBorg or otherwise run in a community-managed way, rather than just by me.
  4. Discuss with nixpkgs stakeholders how the results of these runs could be shown using the Checks API (green check mark, etc) rather than as comment.
  5. Any other community priorities based on feedback.

I know that bot-generated comments are not the ideal way to present these build results. They create an email and a notification to all subscribers on the PR, which can be excessive, especially for prolific contributors. Hopefully future integration with OfBorg and/or the Github Checks API can replace the comments and provide a better experience in the future. In the short term, I want to mention the attempts I have made to address these concerns within the limitations of the “comment-posting model”:

  1. Rather than posting two comments (one for x86_64-linux and one for aarch64-linux) the bot will edit its own prior comment to consolidate both results into a single comment.
  2. If the PR changes only a single nixpkgs attr, the bot runs the build but does not upload the comment, because OfBorg will have already built these PRs completely itself.
  3. If a previous github user has already commented with nixpkgs-review results for a particular platform, the bot will not duplicatively post results for that platform.
  4. If the bot detects various internal errors that might have occurred, most commonly a out-of-memory condition that caused a spurious build failure, it will not post any comment.
  5. (If the comments are particularly bothering you, you can always reach out to me here or on IRC and I can add you to a “quiet list” so your PRs will not receive confirmation comments in the case that all packages built successfully.)

I just wanted to say: keep up the good work! :+1: The output of the bot is often very useful (even though there are sometimes false negatives) and building a reasonable set of dependencies is really the next step beyond/for ofborg.

Integration with the GitHub checks API would indeed be very nice!


ofborg also started with comments, so I think any improvement to the PR workflow is appreciated.

1 Like

Update: the source code for the bot is now here: GitHub - rmcgibbo/r-rmcgibbo


Amazing project! It has been helpful to me so far.

I wonder if it would be useful to re-run the bot after a while if changes have been made to a PR and no other nixpkgs-review has been posted since then. There should probably be a ‘cool down’ period for at least a day, to prevent spamming.


Having the automatic nixpkgs-review is pretty convenient.


I think this would be very useful once the reports can be delivered via Github Checks API (green checkmark), but I’m a little bit more hesitant about posting comments again after new commits on the PR – unless it’s done really carefully it could get spammy.

What do you think about this as an alternative?: Add ability for users to @r-rmcgibbo rebuild to rebuild PR · Issue #3 · rmcgibbo/r-rmcgibbo · GitHub

Just in case anything wonders if such people exist, I am annoyed by OfBorg not doing any of the spammy actions after re-running the checks.