Dan Albert 691e809edb Make service URLs configurable.

Change-Id: I91df77b7e0294be5e6180460b0ef26d7ead2ea7d

2015-01-09 16:18:48 -08:00

3.2 KiB

Raw Blame History

bionicbb

The bionic buildbot contains two services: a gmail polling service, and a web service that interacts with gerrit.

Dependencies

Setup

Create a config.py in the same directory as the sources. The structure of the configuration file is as follows:

client_secret_file = 'CLIENT_SECRET_FILE.json'
build_listener_url = 'BUILD_LISTENER_URL'
jenkins_url = 'JENKINS_URL'
jenkins_credentials = {
    'username': 'JENKINS_USERNAME',
    'password': 'JENKINS_PASSWORD',
}

The client secret file comes from the Gmail API page of the Google Developers Console. The Jenkins credentials are for a Jenkins account that has the appropriate permissions to launch the jobs the buildbot will use.

You will also need to add the HTTP password for the buildbot's Gerrit account to ~/.netrc. The HTTP password can be obtained from the Gerrit HTTP password settings.

To launch the services:

$ python build_listener.py >build.log 2>&1 &
$ python gmail_listener.py >mail.log 2>&1 &

The mail listener will direct your browser to an authentication page for the Gmail API.

gmail_listener.py

Bionicbb polls a gmail account to find changes that need to be built. The gmail account needs to have a gerrit account set up with project watches on anything it finds interesting. This is a rather ugly hack, but it seems to be the simplest option available.

Gerrit does offer a streaming notification service that would be far better, but it is only available over an SSH conection to gerrit, and the AOSP gerrit does not support this connection.

Another option would be polling gerrit itself, but we'd have to process each change every time to see if it should be built, whereas project watches allow us to treat these as semi-push notifications (we still have to poll gmail).

One drawback to this approach is that it's a hassle to set up the project watches for a large number of projects. Since bionicbb is only interested in a small subset of projects, this is a non-issue.

If the buildbot has applied Verified-1 to a patchset, the user may add their own Verified+1 to the change and the buildbot will remove its rejection the next time the services polls (by default, every five minutes).

The service will also listen for the following commands:

bionicbb:clean: Something is very broken and the buildbot's output directory needs to be nuked.
bionicbb:retry: Something went wrong and the buildbot should retry the build.

build_listener.py

The build listener service responds to HTTP POST events sent from Jenkins and updates CLs accordingly. The only other API endpoint is /drop-rejection, which will remove a Verified-1 from a previously rejected patchset. The actually invocation of this is handled by the gmail listener.

3.2 KiB Raw Blame History