New issue
Advanced search Search tips

Issue 920530 link

Starred by 1 user
Status: Assigned
Owner:
hiroh@chromium.org
Cc:
derat@chromium.org
keiichiw@chromium.org
dstaessens@chromium.org
hidehiko@chromium.org
nya@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug



Sign in to add a comment

Get board name for skip test in Tast

Project Member Reported by hiroh@chromium.org, Jan 10 
Because of a driver issue, some video test cases fails on a specific device. For example, see video_VideoEncodeAccelerator [1].
In autotest, we have been skipping those test cases by specifying board name. On the other hand, there is no function to get board name in Tast.
One way i to skip by using autotest-capability. However, I would like to avoid adding many capability in the yaml files and keep as small capabilities as possible.
We will never use this kind of HACK skip ways heavily indeed. Ideally, we should fix all the drivers, but it is hard from time to time due to our bandwidth.
Is it ok to implement this function and use it for media tests?
nya@ and derat@, what do you think?

[1] https://chromium.googlesource.com/chromiumos/third_party/autotest/+/master/client/site_tests/video_VideoEncodeAccelerator/video_VideoEncodeAccelerator.py#64

Comment 1 by derat@chromium.org, Jan 10

Cc: hidehiko@chromium.org
Components: Tests>Tast
I don't want to expose board names to tests since I suspect that test authors will overly depend on this in the future.

I wouldn't object to using autotest-capability here, but I think it's also reasonable to add a new dependency/feature (http://go/tast-deps) with a name like "video_bitrate_switching" and leave it unset on boards that don't support this feature. Hopefully there are USE flags for the relevant chipsets so you won't need to list a bunch of board names in local_test_runner.

Runtime detection is still the best approach, though. Controlling behavior from board names is problematic since it's effectively obsolete with Unibuild.

Comment 2 by hiroh@chromium.org, Jan 10 

> Runtime detection is still the best approach, though. Controlling behavior from board names is problematic since it's effectively obsolete with Unibuild.

Could you elaborate "it's effectively obsolete with Unibuild."?
I guess driver behavior will be the same for boards whose name for unibuild is the same.

Comment 3 by derat@chromium.org, Jan 10 

> Could you elaborate "it's effectively obsolete with Unibuild."?

Sorry for being unclear. My point was that although board-based behavior-switching may work in some cases like this one (since what you really care about seems to be chipsets, and those will likely be the same for all devices that use a single board), it's unlikely to work reliably in other cases in the future with Unibuild since we'll have multiple hardware configs sharing a single board.

Do we set USE flags for the chipsets that you care about?
►

Sign in to add a comment