I think this would be a good feature to support (again, since it used to work).

There are a couple alternatives.

The first, and definitely easier alternative, is that if you're already building what you want locally, you can create an isolate for it and run it under swarming:

https://www.chromium.org/developers/testing/isolated-testing/for-swes#TOC-Run-a-test-built-locally-on-Swarming

The second, if you want to run a change plus certain tests on an arbitrary trybot:

1) Figure out which entries in //testing/buildbot you need to modify. Each trybot has a "matching" waterfall bot, and you can look up the matches in 

https://cs.chromium.org/chromium/build/scripts/slave/recipe_modules/chromium_tests/trybots.py

so, for example, "linux_chromium_dbg_ng" corresponds to "Linux Builder (dbg)" and "Linux Tests (dbg)(1)" on the chromium.linux master

(from https://cs.chromium.org/chromium/build/scripts/slave/recipe_modules/chromium_tests/trybots.py?l=282)

And then you can find the matching entries for those bots in //testing/buildbot/chromium.linux.json in the src repo:

https://cs.chromium.org/chromium/src/testing/buildbot/chromium.linux.json?l=3526
https://cs.chromium.org/chromium/src/testing/buildbot/chromium.linux.json?l=4197

Delete everything from the "additional_compile_targets", "gtest_tests", "scripts", and "isolated_scripts" lists that you don't want to run.

In most cases you can also override or customize the arguments to each test (particularly to select which tests to run, if you only want a subset) by adding an "args" field or a filter file as in

https://cs.chromium.org/chromium/src/testing/buildbot/chromium.linux.json?l=4262

Modify the JSON file, check it in, and upload it to Rietveld or Gerrit, and then trigger the given bot(s) via the UI or the command line as you would normally. Then revert that change when you're done, to make sure you don't check it in :).

Yes, this is something we want to support. (For the sake of pedantry, it used to work with "git try", it has never worked with "git cl try".)

I think that adding this feature is something that the platform team should drive, as I believe it will require a bunch of work to support building smaller unittest targets, and passing target filters into the resulting jobs.

It does work with git cl try!

 $ git cl try --help
...
    -p PROPERTIES, --property=PROPERTIES
                        Specify generic properties in the form -p key1=value1
                        -p key2=value2 etc. The value will be treated as json
                        if decodable, or as string otherwise. NOTE: using this
                        may make your try job not usable for CQ, which will
                        then schedule another try job with default properties
...


Furthermore, CQ will correctly not take such tryjobs into account and will reschedule them instead.

V8 project is already taking advantage of this, since as agable@ correctly mentioned above, V8's recipes understand such properties and then propagate them through isolate to test runners.

So, what's missing is this in Chrome recipes and possible test runners.

I'm marking this as available P2. We're probably not going to get around to implementing this this quarter, but it does seem like a good feature, so we might re-visit it in the future.

Tandrii, is there any documentation about how this works for V8 that you can point to?

Hm, not aware of docs, +machenbach@

From my PoV, it's trivial to get this property from inside recipe. The difficult part is propagating this property to all test runners (and possibly even as early as gn to avoid unnecessary compile & isolate targets). But the good news, is that it's easy to experiment today:
 * CQ won't be accidentally use such tryjobs
 * you have awesome led tool at your disposal: go/led-talk 

We have no specific docs. But agreeing with Andrii. Setting properties is trivial, see comment 5. Those properties will reach the recipe. Then comes the hard part in chromium_test module to teach the recipes what to do with this.

First you need to map the filtering properties to steps somehow (i.e. skip some steps entirely), then pass it to the different types of test-runners (e.g. gtest vs. telemetry vs. layout tests etc.).

Bonus points would be to only compile what is really needed for testing, in order to also speed up this part.

E.g. if I only want to run a specific browser_test, then only browser_tests should be compiled, all other test steps should be skipped, a filter needs to be passed to the browser_tests executable and maybe also swarming shards need to be adjusted on the fly (that's probably tricky). In the simple case, we could keep original shards (e.g. 9) but only run that one test.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

V8 still wants this feature. It'd be particularly helpful to quickly bisect through stuck V8 rolls.