Chromium Buildbot FAQ

Buildbot end of life date is March 1, 2019. As of March 1, all Chromium/Chrome builds hosted on chromium.org will be running on LUCI.

How to setup a new buildbot master?

Please create a LUCI builder instead of Buildbot. Buildbot end of life is March 1, 2019.

go/new-master

1. Determine the host machine for your buildbot master. Refer to go/chrome-infra-mastermap for examples.
   • Do not put an internal master together with public ones. Otherwise public slaves with possibly untrusted code will have network access to your slaves. Typical safe choices for new chrome infra clients: master3 (public) or master7 (internal).
   • If there is mention of a master${num}a machine, prefer that instead of master${num}. Same for master#b, etc.
2. Choose a master name, e.g. master.client.x. The only valid names after the master.__ section are:
   • chromium
   • chromiumos
   • chromeos
   • client
   • tryserver
   • internal
   • official
3. File a slave-request ticket early. Include master's vlan (m3, m7 or so), and slave types (GCE or VMs).
4. Create a new master directory in build/masters or build_internal/masters.
5. Create a builders.pyl file in the master directory describing the builders on this master. You could leave 0 for master_port, master_port_alt and slave_port. mastermap.py will find it for you in later step.
6. Run ../../../build/scripts/tools/buildbot-tool gen . in your master dir to regenerate master configuration. Run it whenever builders.pyl changes.
7. Run ../../../build/scripts/tools/mastermap.py --find <master-class-name> where master-class-name is a name of the class in the generated master_site_config.py. It will search for available master port numbers. If you are creating an internal master, you'll need to run build_internal/scripts/tools/mastermap_internal.py instead. Put the chosen ports into builders.pyl and regenerate the configuration.
8. Add your new master to the list of masters in [build/tests/masters_test.py]: '<master-name>': '<master-class-name>',, so the master is included in presubmit checks.
9. If you were provided with slaves, update builders.pyl.
10. Send the CL, land it.
11. File a master deployment ticket.
12. Add entry in master-manager/desired_master_state.json (e.g. https://chromereviews.googleplex.com/304367013/).

Whenever you modify builders.pyl, e.g. add/remove slaves, you need to restart the master.

How to run buildbot locally for testing?

Commit your changes to a local branch. Many builders will git reset --hard HEAD which will wipe out your local changes.

$ cd build/masters/master.foo.bar
$ make restart

To run a test slave locally to run the build:

$ cd build/slave
$ TESTING_MASTER=FooBar TESTING_MASTER_HOST=localhost TESTING_SLAVENAME=FooSlave make restart

FooBar is the same class name pulled from master_site_config.py above. FooSlave is a slave listed in the builders.pyl, or slaves.cfg that you want to impersonate locally.

How to restart a buildbot master?

Contact a trooper.

How to schedule builds on buildbot from an external system?

Use buildbucket to schedule builds and check their status:

1. Create a build bucket
2. Set buildbucket_bucket attribute in your builders.pyl
3. Set service_account_file attribute in your builders.pyl. File a bug to deploy a new service account, or not sure what service account to use.
4. Call buildbucket.put.
5. Check that your build was created using buildbucket.get or buildbucket.search.
6. Buildbot master will poll the build and schedule it on buildbot.
7. When the buildbot build is completed, buildbucket build will be updated.

How to write a build/test script?

Use recipes