Convert KeyErrors when executing post-process hooks into check failures.

This provides more helpful information when a KeyError occurs because
the check failure will include information about what keys were in the
dictionary and relevant variables to provide information about what
dictionary was accessed.

This is helpful for creating a step object so that attempting to access
missing keys on dict-fields of the step produces helpful output
(attempting to provide the relevant state as part of the implementation
of the fields was drastically increasing the complexity). It also removes
the need for the StepsDict type to get helpful error messages when
attempting to access a missing step.

The code for checking for KeyErrors when producing variable information
enables the use of common idioms involving short-circuiting logical
operators: "check(key in d and d[key] == some_value)" and
"check(key not in d or d[key] != value)".

Change-Id: I4470a42520d1ceb82bdba2e0f472ddf22d204c32
Bug: 939120, 946015
Reviewed-by: Robbie Iannucci <>
Commit-Queue: Garrett Beaty <>
3 files changed
tree: d7931562a64cf510bb36c8736b861b96b9ec31e7
  1. .gitattributes
  2. .gitignore
  3. .vpython
  11. codereview.settings
  12. doc/
  13. infra/
  14. misc/
  15. recipe_engine/
  16. recipe_modules/
  17. recipe_proto/
  19. recipes/
  20. unittests/


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



    This file!

  • doc/

    Documentation for the recipe engine (including this file!). See the design doc for more detailed design information about the recipe engine.

  • infra/

    Chrome infra config files.


    The main entry point to the recipe engine. It has many subcommands and flags; run -h to see them. Include this in your repository to start using recipes.

  • recipes/

    Recipes in the recipe engine. These are either example recipes, or recipes which are used to test the engine (see to see these run)

  • recipe_modules/

    Built in recipe modules. These are very useful when writing recipes; take a look in there, and look at each of their examples subfolders to get an idea how to use them in a recipe.

  • recipe_engine/

    The core functionality of the recipe engine. Noteworthy files include:

    • -- The main entrypoint for the recipe engine.
    • recipes_cfg.proto -- The protobuf file which defines the format of a recipes.cfg file.
    • third_party/ -- third_party code which is vendored into the recipe engine.
    • -- The api exposed to a recipe module.
    • unittests -- Unittests for the engine.

    There are also several files which correspond to a subcommand of; run, and autoroll are some examples.

  • unittests/

    Somewhat poorly named, these are higher level integration tests.


  • Sign the Google CLA.
  • Make sure your and are configured in git config.

Run the following to setup the code review tool and create your first review:

git clone $HOME/src/depot_tools
export PATH="$PATH:$HOME/src/depot_tools"
git checkout -b work origin/master

# hack hack

git commit -a -m "This is awesome"
# This will ask for your Google Account credentials.
git cl upload -s -r
# Wait for approval over email.
# Click "Submit to CQ" button or ask reviewer to do it for you.
# Wait for the change to be tested and landed automatically.

Use git cl help and git cl help <cmd> for more details.