| commit | 78b43ec434fc1fc1ae67023923cacd7c9884c7d2 | [log] [tgz] |
|---|---|---|
| author | Vadim Shtayura <vadimsh@chromium.org> | Tue Jan 08 20:29:37 2019 |
| committer | Commit Bot <commit-bot@chromium.org> | Tue Jan 08 20:29:37 2019 |
| tree | 4d35fc35c84a7cc8ba1399de2201d0437947fe0f | |
| parent | 80712f8b382bbdae855ec0d1d01f6d6170a94981 [diff] |
[lucicfg] Be careful when mixing assert.fails(...) and fail(...) builtin. fail(...) builtin uses a thread local state (FailureCollector) to capture structured information about an error (because Starlark stringifies all errors returned by a builtin). assert.fails(...) "catches" starlark errors, but it doesn't clear the captured error in the thread local state. Fixing this would require forking assert library, which I'd like to avoid. So instead just don't use failure collector in tests that don't care about extra information (like custom stack trace) attached to errors. In lucicfg only tests that use "Expect errors" blocks care about custom stack traces, and they generally do not use 'assert' library. R=tandrii@chromium.org BUG=833946 Change-Id: I06d9f8fe48c6720070141a4d2e2bcd3d9d88584a Reviewed-on: https://chromium-review.googlesource.com/c/1397345 Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org> Commit-Queue: Vadim Shtayura <vadimsh@chromium.org>
LUCI Go code is meant to be worked on from an Chromium infra.git checkout, which enforces packages versions and Go toolchain version. First get fetch via depot_tools.git then run:
fetch infra cd infra/go eval `./env.py` cd src/go.chromium.org/luci
Contributing uses the same flow as Chromium contributions.