Assigning to the gardner so this doesn't get lost.

The test is part of the 'android_video_decode_accelerator_unittests' target in media/gpu, which is included in video_decode_accelerator_unittest, which has this comment:

# TODO(watk): Run this on bots. http://crbug.com/461437

+watk@

It is also included in media/media_unittests, and is part of "gn_all" (which probably isn't built anywhere), "chrome_official_builder" (if is_win), and "chromiumos_preflight" (if is_chromeos). 

You may need to dig in to which gn targets are run on which builders and update a target.

I'm confused re #1. jpeg_decode_accelerator_unittest is a chromeos only test target. Did you confuse it with video_decode_accelerator_unittest perhaps? 

Hmm, apologies, ignore comment #1, my I must have miss copy/pasted my search.

jpeg_decode_accelerator_unittest does not appear to be referenced elsewhere in the chromium code.

It is however referenced directly in the chromeos-chrome ebuild, which is unusual:

https://cs.corp.google.com/chromeos_public/src/third_party/chromiumos-overlay/chromeos-base/chromeos-chrome/chromeos-chrome-9999.ebuild?q=jpeg_decode_accelerator_unittest&l=693

It appears to be run by video_JpegDecodeAccelerator.py.

This is kind of unfortunate since the first time this will break is in the PFQ informational builders.

+jcliang@

I'm not sure what the right solution is here, but ihf@ has been involved in the recent discussions about trying to minimize PFQ breakage, so maybe has some thoughts on this.

Can we add jpeg_decode_accelerator_unittest.cc as a target of the following two trybots?

- chromeos_daisy_chromium_compile_only_ng
- chromeos_amd64-generic_chromium_compile_only_ng

We could. It's weird and confusing because we do not usually run Chrome unit tests in a Chrome OS environment (including Simple Chrome).

Ideally I think we should have a special target, something like "autotest_unittests", for tests that get run on a device in an autotest (even if it is just this one, but we should also check to see if there are others).

Then, adding that target, with a comment, to the simple chrome builders mentioned in comment #4 would make sense to me.

Since the original problem was that the JDA did not compile and the cq did not catch it, adding JDA as a build target would fix the issue.

We're working on adding fully functional chromeos bots to the chrome cq. Currently the chromeos bots are compile-only and do not run any chrome tests. Once the chromeos bots are set up we will have both compile and test coverage.

The "autotest_unittests" bot sounds like a good plan, but it'll probably require more effort to replicate the autotest environment in chrome lab. It can be a stretch goal once we have the chromeos bots set up.

Sure, we can fix things for just this particular instance that broke, however, here is the list of additional targets we build in the ebuild:

https://cs.corp.google.com/chromeos_public/src/third_party/chromiumos-overlay/chromeos-base/chromeos-chrome/chromeos-chrome-9999.ebuild?l=692

I was not suggesting that we attempt to run them, just add an extra GN target and build them in the simple chrome builders.

(While we do plan to run a few VMTests in the Simple Chrome builders on the Chromium waterfall, those will be kept to a minimum and we are unlikely to actually run these tests, but it definitely makes sense to build them.)

Ah, I see. Sorry I misread you in #5. Having a autotest_unittests GN target makes sense. We're actually suggesting the same approach which is to get compile coverage in the builders first.

Ultimately we'd want to run Chrome unit tests on the simple chrome builders as well with the tests running on real chromeos devices. Lacking Chrome CQ coverage has caused lots of regressions in the VDA and VEA unit tests on Chrome OS and today we usually learn the regression on the chromeos-chrome PFQ which is too late.

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

This bug has an owner, thus, it's been triaged. Changing status to "assigned".