Repository files navigation

Scabot (pronounced ska-BOH) helps shepherd pull requests in theScala repository along the path from initial submission to final merge.

Scabot tries to stay behind the scenes. It speaks to us through actions rather than words, where possible.You shouldn't have to tell it what to do, unless something goes wrong (usually Jenkins acting up).

Scabot works by listening to webhook events from GitHub andour CI server.

It can be summoned (immediately!) through certain commands, posted as pull request comments (see below).

• Trigger CI builds for commits, keeping us informed of their progress. (It will also pick up the results of manual rebuilds done directly on the CI server.)
• Set milestone of a PR based on its target branch.
• Add reviewer request when there's a comment like "review by @authorityfigure"(obsolete feature, we use GitHub's built-in reviewing features instead now)
• For its ambitions, check outScabot's issues.

• /rebuild: rebuild failed jobs for all commits
• /rebuild $sha: rebuild failed jobs for a given commit
• /sync: make sure that commit stati are in sync with the actual builds on theCI server.
• /nothingtoseehere: mark commits green without actually running CI on them

• [ci: last-only]: include anywhere in the PR title to avoid verifying all commits, limiting CI to the last one

For ssh access to the server running the bot, this assumes you're using ourdev machine setup.

Scabot runs on the CI server under thescabot account. Wepush to deploy. (The deployment process could maybe be redone at some point using sbt-native-packager's JavaServerAppPackaging (seesbt/sbt-native-packager#521) -- or whatever Play folks usually use, now that Scabot is a Play/Akka app, not just Akka anymore.)

(If push-to-deploy isn't working,this might help.)

ssh jenkins-master, andjournalctl -u scabot (add-f to see the tail, perhaps with-n 1000 to see more lines)

ssh jenkins-master, andsystemctl restart scabot

To check if everything seems okay after restart,journalctl -u scabot -b -f to follow (-f) the logs since last boot (-b)

The Scabot code includes a suite of methods corresponding to variousAPI calls, returning instances of case classes representing theJSON responses from the API calls. You can use these methods from theScala REPL to do your own queries. Here is a sample session. Notethat for API calls that interact with GitHub, you must supply apersonal GitHub API access tokenwhen starting sbt.

% sbt -Dscabot.github.token=... cli/consoleWelcome to Scala ......scala> val c = new scabot.cli.CLI("scala")c: scabot.cli.CLI = ...scala> val pulls = c.await(c.github.pullRequests)pulls: List[c.PullRequest] =List(PullRequest(...), ...)scala> pulls.filter(_.user == c.User("retronym")).map(_.number)res0: List[Int] = List(4535, 4522)scala> c.shutdown()

It's Akka-based. ("My first Akka app", Adriaan says.)

It uses Spray to make web API calls. (These days, maybe it should be using akka-http instead, if/when its SSL support is mature.)

Pull request statuses are updated using GitHub'sStatus API.

We listen for webhook events, but just in case we missed some, aSynch event triggers on startup and every 30 minutes thereafterto make sure that our internal state is still in synch with reality.

In the SBT build, the root project aggregates five subprojects.server depends onamazon,github, andjenkins; all ofthem depend oncore. (TODO: just makeserver be the root project?)

Theamazon subproject uses DynamoDB to persist ascabot-seen-commandstable, so atSynch time we don't reprocess stuff we already handledonce.

A good place to start exploring the code isserver/src/main/scala/Actors.scala.

PR status is updated in response toPullRequestEvent messages,which might be real events coming directly from GitHub, or they mightsynthetic ones we make whenSynching.

Old-timers may fondly remember Scabot's predecessor, theScala build kitteh.

Yes, please!