Chromium OS‎ > ‎Chromium OS Build‎ > ‎

Chromium OS Remote Trybots

Contents

  1. 1 Introduction
  2. 2 Instructions For Using the Remote Trybot
    1. 2.1 To patch in a gerrit CL
    2. 2.2 To patch in a rietveld CL
    3. 2.3 To patch in a local change:
    4. 2.4 Testing on a release branch
  3. 3 Other useful flags
  4. 4 Recommended Trybot Runs Before Checkin

Introduction

Sorry, but this is only available to Google employees at the moment. Make sure you've joined the chromeos-team group.

Remote trybots allow you to perform a trybot run of multiple configs/boards in parallel on remote servers.  A trybot allows you to emulate a buildbot run with a set of your changes. The changes are patched to tip of tree (TOT).  It supports running of Paladin, incremental, and full buildbot configurations.

It supports patching of both gerrit CL's and changes you've committed locally but haven't uploaded.

The remote trybot waterfall is located at https://uberchromegw.corp.google.com/i/chromiumos.tryserver.

Instructions For Using the Remote Trybot

Run the following from within your repo source checkout:

  1. IMPORTANT! run repo sync chromiumos/chromite to get latest version of cbuildbot.
  2. Run cbuildbot --list to see a list of common configs to run with.  Use the --all flag to see all possible configs.  The possible configurations are also displayed on the trybot waterfall.

To patch in a gerrit CL

3a. Run

cbuildbot --remote -g [*]<cl_1> [-g ...] config [config...]

Substitute [config [config...]] with a space-separated list of your desired configs. Prepend a '*' to the CL ID to indicate it's an internal CL. The CL ID can be a Gerrit Change-ID or a change number.

An example:

cbuildbot --remote -g 4168 -g *1234 alex-paladin x86-alex-release

This runs a tryjob for the alex-paladin and x86-alex-release configs in parallel. It patches in two CL's: 1) an external CL using a Gerrit change number 2) an internal CL using a Gerrit change number. In case a CL has several patches associated with it, the latest patch is used.

Note that specifying the same configuration multiple times is permitted. This will cause multiple instances of the same config to be tried in parallel.

To patch in a rietveld CL

3b. Run

cbuildbot --remote --rietveld-patches=id[:subdir1]...idN[:subdirN]

For example, this patches CL 356903002 into Chrome's /src directory and tries one bot:

cbuildbot --remote --rietveld-patches=356903002 x86-generic-tot-chrome-pfq-informational

This patches 11659002 into chromium/src/tools/gyp and tries two bots:

cbuildbot --remote --rietveld-patches=11659002:src/tools/gyp x86-alex-paladin x86-alex-release

If you are asked for a username and password check your ~/.netrc. If you don't see entries for chromium.googlesource.com you need to generate a new password.

Internal rietveld CLs are not yet supported.

To patch in a local change:

3c. To patch in a local patch, run:

cbuildbot --remote -p <project1>[:<branch1>] [-p ...] config [config..]

Specify the name of the project (not the path, look for projectname in .git/config) and optionally the project branch. If no branch is specified the current branch of the project will be used.

An example:

cbuildbot --remote -p chromiumos/chromite -p chromiumos/overlays/chromiumos-overlay:my_branch x86-generic-paladin amd64-generic-paladin

This patches in any commits in project chromiumos/chromite's current branch and on branch 'my_branch' in project chromiumos/overlays/chromiumos-overlay.

Testing on a release branch

3d. To test patches for a release branch (i.e., R20, R21) use the --branch (-b) option with -g:

cd <repo_root>/chromiumos/chromite
git checkout cros/master
cbuildbot --remote -b release-R20-2268.B -g 4168 alex-paladin

Local patches (-p) to branches are not yet supported.
Non-release branches such as factory, u-boot, etc. are not yet supported.

3e. To create an official release using tryjobs from a branch:

cd <repo_root>/chromiumos/chromite
git checkout cros/master
cbuildbot --remote --buildbot -b stabilize-4731.62.B butterfly-release

In the case where you would like all boards built (*-release[-group]), just list each try config separated by spaces.

Caveats:

  • Every time you launch a set of builders, each builder (except x86-mario-release, which is the master builder) will look at whether it has built the previous release. If the previous release was not built, the builder will build the last release.
  • If you launch the same set of builders for a release every time, the above logic will work great, because all of the builders will build the same code, even if the trybot server is busy and we can't actually launch all of the bots at once.
  • If you try to switch what boards are built on a branch, the above logic can cause problems. For example, if you first build "spring" for a branch, and then, a few days later, try to create a new release with "parrot" instead, the builder will try to "catch up" and build the previous release, ignoring any new changes that have been checked into the branch since the spring release.
  • To avoid the above problem when adding new boards to a branch, it is a good idea to first launch builds for the master builder (x86-mario-release) and then, after the ManifestVersionedSync stage has completed, launch the new builders you want to build.
Need build daisy from a branch:
cbuildbot --remote --buildbot -b stabilize-4731.62.B daisy_spring-release
Now we've landed more changes on stabilize-4731.62.B in order to fix something for parrot:
cbuildbot --remote --buildbot -b stabilize-4731.62.B x86-mario-release
wait until the "ManifestVersionedSync" step has completed on this job, then:
cbuildbot --remote --buildbot -b stabilize-4731.62.B parrot-release

4. Wait for the result (fail/pass) emails from the remote trybot server. 

5. Optionally download the archived artifacts that the trybot uploaded by clicking on the link in the result email.

Other useful flags

--remote-description

Attach an optional description to a --remote run to make it easier to identify the results when it finishes.(eg: “testing CL:1234 after fixing NameError”).

Recommended Trybot Runs Before Checkin

Before you check in something, you should at least run it once through trybot with an x86 paladin config, once with an amd64 paladin and once with a daisy paladin config.  However, to be even more sure that your change won't break the tree, you can run a full or release config.

Please file any bugs on the chromium tracker under the labels Build-Tools-cbuildbot and OS-Chrome

Comments