| commit | 5c575266cf91a14adf9b17c71f4e4e03ad964c24 | [log] [tgz] |
|---|---|---|
| author | Oliver Newman <olivernewman@google.com> | Mon Jun 01 23:24:41 2020 |
| committer | LUCI CQ <infra-scoped@luci-project-accounts.iam.gserviceaccount.com> | Mon Jun 01 23:24:41 2020 |
| tree | da3b8feb11d0c340a4e1d7510eb27c5d8be481f7 | |
| parent | 8305d8fd87b19e4f63db30ac7ea9d52f1fc2093c [diff] |
[post_process] Make failure output less noisy
If a test case has `api.post_process(StepFailure)` and it *doesn't*
fail, we currently get some pretty verbose and confusing output:
CHECK(FAIL):
.recipe_deps/recipe_engine/recipe_engine/post_process.py:452 - StatusFailure()
`check(('failure' in step_odict['$result']['failure']))`
step_odict['$result'].keys(): ['name']
raised exception: KeyError: 'failure'
added recipes/some_recipe.py:123
StatusFailure()
With this change it still won't be very clear, but it'll at least be
slightly less verbose and hopefully less confusing without the
`KeyError` line:
CHECK 'expected failure but recipe succeeded' (FAIL):
.recipe_deps/recipe_engine/recipe_engine/post_process.py:452 - StatusFailure()
`(not check('expected failure but recipe succeeded', ('failure' in result)))`
result.keys(): ['name']
added recipes/some_recipe.py:123
StatusFailure()
Note that these error messages are inconsistent with the
`post_process()` documentation, which says that "hints should be written
as the ___ in the sentence 'check that ___.'":
https://chromium.googlesource.com/infra/luci/recipes-py/+/2438e081638a16b8de53752c5a78c807195ed186/recipe_engine/recipe_test_api.py#615
In this case, writing hints in that form yields very confusing error
messages, so I think it's a worthwhile tradeoff.
Change-Id: If6e5a5a1b7c098bd23d80d3a5c1193dbeb7eb8c0
Reviewed-on: https://chromium-review.googlesource.com/c/infra/luci/recipes-py/+/2144492
Commit-Queue: Oliver Newman <olivernewman@google.com>
Reviewed-by: Robbie Iannucci <iannucci@chromium.org>
Recipes are a domain-specific language (embedded in python) for specifying sequences of subprocess calls in a cross-platform and testable way.
They allow writing build flows which integrate with the rest of LUCI.
Documentation for the recipe engine (including this file!). Take a look at the user guide for some hints on how to get started. See the implementation details doc for more detailed implementation information about the recipe engine.
user.email and user.name are configured in git config.Run the following to setup the code review tool and create your first review:
# Get `depot_tools` in $PATH if you don't have it git clone https://chromium.googlesource.com/chromium/tools/depot_tools.git $HOME/src/depot_tools export PATH="$PATH:$HOME/src/depot_tools" # Check out the recipe engine repo git clone https://chromium.googlesource.com/infra/luci/recipes-py $HOME/src/recipes-py # make your change cd $HOME/src/recipes-py git new-branch cool_feature # hack hack git commit -a -m "This is awesome" # This will ask for your Google Account credentials. git cl upload -s -r joe@example.com # 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.