commit 9f094b4a0ae44b7af0176a2553e0844d0ae4cd9c
author Ben Pastene <bpastene@chromium.org> Thu Jul 11 22:48:01 2024
committer LUCI CQ <infra-scoped@luci-project-accounts.iam.gserviceaccount.com> Thu Jul 11 22:48:01 2024
tree f1a9cd540153de62665c2abfae680a02fbdd1bfd
parent 6990db4626f9cf85b1785a5ef675a8ae06219eac

utr: Disable resultdb for tests that run locally

Right now, when running a local script test via the UTR, you get
obscure rdb errors:
http://screen/B2n58vas2vKgJuv

That's due to some issue in the plumbing of the realm to the resultdb
command. However, we shouldn't be running resultdb for such tests
anyway, the reason being that we don't want local results uploaded
to resultdb. There's more details at http://launch/4324230.

So, this CL will make the UTR explicitly disable resultdb for any
such tests by:
- Forcing the "resultdb.enable" field for all test's specs to False,
  which will prevent the cmd from being wrapped in `resultdb ...`.
- Also wrapping the test command in a new script added here, called
  reset_luci_context.py. This script will replace the current
  LUCI_CONTEXT with a new one, with any result_sink info removed. This
  is just in case the script is smart enough to detect that itself
  and write its own results to the sink server, eg: https://source.chromium.org/chromium/chromium/src/+/main:build/util/lib/results/result_sink.py;drc=5537f5499ed7230b4b59c60fad370465617afda0;l=41

This will make all local script tests run by the utr actually launch
successfully. Any failures won't be uploaded to resultdb, so the UX
of inspecting failures won't be great. Instead, the user will have to
scroll up in output to inspect the stderr of the script test. But
that's at least better than not running the test at all.

A series of follow-up CLs will be coming to make the UX of that
better in the output. (By e.g. clarifying that as needed in the
final "https://luci-milo.appspot.com/ui/inv" line that gets printed
in the output.)

Note that taking a test that normally runs on swarming and making
it run locally still isn't supported. But _if_ we wanted to support
that, this should lay some groundwork to make that a little
easier/safer.

Bug: 41492686
Change-Id: Ic668d842121bd18a9ffb7034c93af696f9ecf911
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/tools/build/+/5692415
Reviewed-by: Garrett Beaty <gbeaty@google.com>
Reviewed-by: Struan Shrimpton <sshrimp@google.com>
Commit-Queue: Ben Pastene <bpastene@chromium.org>