Recipes (go/recipe-docs)

Recipes are a domain-specific language (embedded in python) for specifying sequences of subprocess calls in a cross-platform and testable way.

• User guide
• Recipe and recipe module documentation:
  • recipe_engine
  • depot_tools
  • build
  • build internal (internal link)
  • infra

Recipe Roller

Builder page (internal link).

The recipe roller is a service that ensures that the pinned dependencies between recipe repositories are kept up to date. At the time of writing, the dependencies between repositories are as in the following diagram:

 +----recipe_engine------------+
 |     |    |                  |
 |  +--+    |                  |
 |  |       |                  |
 |  |       v                  |
 |  |  depot_tools----------+  |
 |  |  |    |               |  |
 |  |  |    |               |  |
 |  |  |    v               v  v
 +------->build------->build_internal
    |  |      |
    |  +---+  |
    |      v  v
    +---->infra

The recipe roller rolls changes downward through this graph every 10 minutes.

Additionally, the roller tries to keep the skia and fuchsia infra repos up to date as well.

For recipe authors:

• “Trivial” Rolls: If your change produced no expectation changes downstream, the roller will automatically CR+1 and CQ+2 the roll. The CQ may (depending on how its configuration), apply additional tests to the roll, but for the most part these rolls will go through without issue.

• “Non-trivial” Rolls: If your change produced some expectation changes downstream, you will get a review from recipe-roller@chromium.org with those changes. if they look good, cr+1 and cq+2 them. if the if they don‘t look good, revert the upstream patch that’s being rolled in. Leaving a change un-rolled blocks other changes from being rolled, and causes a build-up of changes that is hard to manage.

• “Error” Rolls: Sometimes upstream changes cause errors when the roller operates that prevents the creation of a downstream patch. These always require manual resolution, usually in the form of a revert of the upstream patch, or a CL to the downstream repo. Examples of these sorts of rolls would be changing a function signature that's in use by downstream repos, or removing some piece of configuration from the upstream repo which is in use by the downstream repo. A good way to resolve these is to move the upstream code to the downstream repo. The best way to prevent these sorts of errors is to move the code downstream first, and then remove it from the upstream repo.

Roller implementation

For more information about the autoroller implementation, please refer to the:

• Roll algorithm implementation.
• Autoroller recipe module.
• Autoroller recipe.