tree: caee82665a02ee79b4eb04879008ea2d8cc2aa86 [path history] [tgz]
  1. checkout/
  2. manifest/
  3. props/
  4. main.go
  5. main_test.go
  6. README.md
cmd/recipe_bootstrap/README.md

Recipe Bootstrapping

The recipe bootstrapping tool reads a build.proto from stdin, resolves the appropriate recipe version to use, and executes the build.

The tool implements the luciexe protocol. Fuchsia Buildbucket builders which require recipe versioning should configure the tool as their executable. See the lucicfg documentation for more information.

Recipe version resolution

The “recipe version” is a recipes.git revision, which is resolved through a decision tree on build.proto. See main file.

Recipe checkout & execution

Once the recipe version is resolved, a checkout of recipes.git is performed. Within the checkout, recipes.py luciexe is exec'd to advance into build execution.

Properties

recipe_bootstrap reads several optional builder properties to determine its behavior:

recipe_integration_remote

Example: “https://fuchsia-internal.googlesource.com/integration

If a build is triggered by a cron schedule rather than by a commit (via LUCI Scheduler) or CL (via Commit Queue), then it won't have a gitiles_commit or gerrit_change in its input.

For public builders it's safe to fall back to using the public integration repository. However, many internal builders assume access to the internal integration repository, so they need to fall back to using internal integration instead.

recipe_integration_remote lets internal builders that may be triggered on a cron job fall back to checking out the specified integration repository (generally the internal integration repository) rather than the default.

recipes_host_override

Example: “fuchsia.googlesource.com”

Some builders are triggered by commits in Git-on-Borg repositories that are not on one of the Fuchsia-owned Git-on-Borg hosts. Only Fuchsia-owned hosts have integration repositories, so for these builds it‘s not valid to try to checkout the integration repository that’s on the same host and ref as the triggering commit.

To avoid that, a builder that‘s triggered by a non-Fuchsia-owned repo can set recipes_host_override to hostname of the Fuchsia-owned Git-on-Borg instance that holds the desired integration repository. If recipes_host_override is set, we use the refs/heads/master ref for checkout because there’s no guarantee for non-Fuchsia-owned repositories that the triggering ref will correspond to a ref of the integration repository.