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.
The “recipe version” is a recipes.git revision, which is resolved through a decision tree on build.proto. See main file.
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.
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.