Webtools/leeroy

LeeroyBot runs tests pull requests before they're merged. Read more about it on the WebDev Blog.

Getting Leeroy set up for your project

• Create a new job on ci.mozilla.org
  • job name '[your job name]_github'
  • copy existing job
• Configure your new job
  • Job Notifications
    • Add Endpoint
      • HTTP
      • http://leeroybot.herokuapp.com/notification/jenkins
    • Check "This build is parameterized"
      • add String Parameter
        • name "GIT_BASE_REPO"
        • default value: mozilla/[project name]
      • add String Parameter
        • name "GIT_HEAD_REPO"
        • default value: mozilla/[project name]
      • add String Parameter
        • name "GIT_SHA1"
        • default value: "master"
      • add String Parameter
        • name "GITHUB_URL"
        • default value: *leave blank*
  • Source Code Management
    • Git
      • repository url: "git://github.com/$GIT_HEAD_REPO.git"
      • branches to build
        • Branch Specifier: "$GIT_SHA1"
  • Build Triggers
    • Trigger builds remotely (e.g., from scripts)
      • Generate a random key
  • remove any build artifact archiving and fingerprinting
  • (optional) remove any notifications to IRC or e-mail
  • (optional) remove any non-test steps such as coverage, leeroy only cares about pass / fail
• Configure Github
  • Add LeeroyBot (https://github.com/leeroybot ) to your team if he isn't already
    • LeeroyBot is controlled by Lonnen, not a third party
    • necessary to set up hooks and use the status API
• File a bug in your product
  • example: bug 805209
  • assign to :Lonnen
  • summary "hook up leeroy"?
  • include
    • github_repo: "mozilla/[your project]"
    • jenkins_job_name: "[your job name]_github"
    • Lonnen will find the token, don't include that in a public bug
• After Leeroy has been updated
  • open a pull request that should not break the build
    • make a trivial documentation change
    • close after it passes
  • open a pull request that will break the build
    • delete models.py
    • close after it fails
  • link both in the bug and mark it resolved -> fixed
  • It's important that these requests are opened or updated /after/ integration is established.

Troubleshooting

Leeroy listens to events as they happen with no queue or storage. If a network event is dropped and something gets stuck in a strange state, the only thing you can do is change the sha or open a new PR. There is an issue open on leeroy to change this. Until then, I suggest adding a trivial commit (add some whitespace to your readme) and rerunning, then popping that commit off the PR with a rebase after it passes.

There's a bugzilla component for filing problems with Leeroy itself: https://bugzilla.mozilla.org/enter_bug.cgi?product=Webtools&component=Leeroy

Rerunning Jobs

Go grab https://github.com/lonnen/leeroy-rerun and run it locally using http://leeroybot.herokuapp.com as your leeroy host. The readme has more details. Should be as simple as copypasta'ing some pull request urls. If there are any problems, file them at the component above.

If that sounds like entirely too much work, you can use this helper script. This will only work if you are working on a repo under the Mozilla Github organization (ie: https://github.com/mozilla). The first argument is the name of the project (to fill in the Github url) and the second is the pull request number.

Gist: https://gist.github.com/4151152