gecko-dev/taskcluster/ci/test/reftest.yml

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

188 строки
5.6 KiB
YAML
Исходник Обычный вид История

# This Source Code Form is subject to the terms of the Mozilla Public
# License, v. 2.0. If a copy of the MPL was not distributed with this
# file, You can obtain one at http://mozilla.org/MPL/2.0/.
---
job-defaults:
Bug 1523303 - [taskgraph] Define suite "categories" rather than flavours task configs, r=gbrown Currently we have the concept of a "suite" and a "flavour" in our task configuration. Typically, the "suite" refers to the high-level test harness like "mochitest" or "reftest", whereas the flavour is more specific, e.g "browser-chrome-instrumentation" or "crashtest". However the line between suite and flavour is not applied with any semblance of consistency which results in inconsistent naming throughout the tree. This patch gets rid of the concept of "flavours" entirely (at least when it comes to task configuration). A suite is a type of test run, for example: - mochitest-plain - mochitest-devtools-chrome - mochitest-browser-chrome-instrumentation - jsreftest - reftest - firefox-ui-functional-remote etc There is no confusion here between suites and flavours because flavours don't exist. However, there are a couple of places where we *do* need to know what "test harness" is used to run a suite. These cases are: 1. For SCHEDULES moz.build rules 2. For the desktop_unittest.py mozharness script which takes arguments like --mochitest-suite=browser (this is not a compelling use of this information and should be refactored to work more like the android_emulator_unittest.py script) So to get this information, this patch introduces a new concept of a "category" which is the overall "test harness" that runs the suite. For many suites, the "category" is identical to the suite name. Unlike flavours, "categories" have no bearing on how we call or refer to the suite. Differential Revision: https://phabricator.services.mozilla.com/D27554 --HG-- extra : moz-landing-system : lando
2019-04-22 23:44:01 +03:00
suite:
category: reftest
target:
by-test-platform:
android-em-7.*: geckoview-androidTest.apk
default: null
variants:
by-test-platform:
linux64/debug: ['fission', 'serviceworker']
default: ['fission']
run-on-projects:
by-test-platform:
android-em-4.*/.*: ['try', 'mozilla-central'] # bug 1548659
windows10-aarch64/opt: ['try', 'mozilla-central']
default: built-projects
mozharness:
script:
by-test-platform:
android-em.*: android_emulator_unittest.py
android-hw.*: android_hardware_unittest.py
default: desktop_unittest.py
config:
by-test-platform:
android-em-7.*:
- android/android_common.py
- android/androidx86_7_0.py
android-em-4.*:
- android/android_common.py
- android/androidarm_4_3.py
android-hw.*:
- android/android_common.py
- android/android_hw.py
linux.*:
- unittests/linux_unittest.py
- remove_executables.py
macosx.*:
- unittests/mac_unittest.py
windows.*:
- unittests/win_unittest.py
crashtest:
description: "Crashtest run"
treeherder-symbol: R(C)
instance-size:
by-test-platform:
android-em.*: xlarge
default: default
virtualization:
by-test-platform:
windows10-64(?:-pgo|-shippable)?-qr/.*: virtual-with-gpu
default: virtual
chunks:
by-test-platform:
android-em-4.*\/debug: 10
android-em-4.*\/(?:opt|pgo)?: 4
android-em-7.*: 1
default: 1
e10s: true
max-run-time:
by-test-platform:
android-em.*: 7200
default: 3600
tier:
by-test-platform:
windows10-aarch64.*: 2
android-em-4.*/.*: 2 # bug 1548659
default: default
jsreftest:
description: "JS Reftest run"
Bug 1523303 - [taskgraph] Define suite "categories" rather than flavours task configs, r=gbrown Currently we have the concept of a "suite" and a "flavour" in our task configuration. Typically, the "suite" refers to the high-level test harness like "mochitest" or "reftest", whereas the flavour is more specific, e.g "browser-chrome-instrumentation" or "crashtest". However the line between suite and flavour is not applied with any semblance of consistency which results in inconsistent naming throughout the tree. This patch gets rid of the concept of "flavours" entirely (at least when it comes to task configuration). A suite is a type of test run, for example: - mochitest-plain - mochitest-devtools-chrome - mochitest-browser-chrome-instrumentation - jsreftest - reftest - firefox-ui-functional-remote etc There is no confusion here between suites and flavours because flavours don't exist. However, there are a couple of places where we *do* need to know what "test harness" is used to run a suite. These cases are: 1. For SCHEDULES moz.build rules 2. For the desktop_unittest.py mozharness script which takes arguments like --mochitest-suite=browser (this is not a compelling use of this information and should be refactored to work more like the android_emulator_unittest.py script) So to get this information, this patch introduces a new concept of a "category" which is the overall "test harness" that runs the suite. For many suites, the "category" is identical to the suite name. Unlike flavours, "categories" have no bearing on how we call or refer to the suite. Differential Revision: https://phabricator.services.mozilla.com/D27554 --HG-- extra : moz-landing-system : lando
2019-04-22 23:44:01 +03:00
schedules-component: jsreftest
treeherder-symbol: R(J)
instance-size: default
chunks:
by-test-platform:
android-hw.*\/debug: 12
android-hw.*/(opt|pgo)?: 6
windows.*: 2
windows10-64-ccov/debug: 5
linux64-ccov/.*: 5
linux64-qr/opt: 4
linux64-qr/debug: 5
linux64/debug: 5
macosx.*64-ccov/debug: 5
default: 3
max-run-time:
by-test-platform:
android-em.*: 7200
windows10-64-ccov/debug: 7200
macosx.*64-ccov/debug: 7200
default: 3600
tier:
by-test-platform:
windows10-aarch64.*: 2
android-em-4.*/.*: 2 # bug 1548659
default: default
run-on-projects:
by-test-platform:
android-em-4.*/.*: ['try', 'mozilla-central'] # bug 1548659
windows10-aarch64/opt: ['try', 'mozilla-central']
android-hw-.*-api-16/debug: ['try', 'mozilla-central']
default: built-projects
reftest:
description: "Reftest run"
treeherder-symbol: R(R)
instance-size:
by-test-platform:
android-em.*: xlarge
default: default
virtualization: virtual-with-gpu
chunks:
by-test-platform:
android-em-4.*\/debug: 56
android-em.4.*\/(?:opt|pgo)?: 28
android-em-7.*: 5
linux64(-shippable|-devedition|-qr)?/opt: 5
macosx101.*-64/opt: 2
macosx101.*-64/debug: 3
macosx.*64-ccov/debug: 6
windows.*/opt: 2
windows.*/debug: 4
windows10-64-ccov/debug: 6
default: 8
e10s: true
max-run-time:
by-test-platform:
android-em.*: 7200
windows10-64-ccov/debug: 5400
windows10-64-asan/opt: 5400
macosx.*64-ccov/debug: 5400
default: 3600
mozharness:
chunked:
by-test-platform:
android-em.*: false
macosx.*64/opt: false
windows10-64.*/opt: false
default: true
tier:
by-test-platform:
windows10-aarch64.*: 2
default: default
reftest-gpu:
description: "Reftest GPU run"
treeherder-symbol: R(Rg)
chunks:
by-test-platform:
windows.*/opt: 2
default: 4
run-on-projects:
by-test-platform:
windows10.*: []
default: built-projects
instance-size: default
virtualization: virtual-with-gpu
max-run-time: 3600
mozharness:
chunked: true
tier: default
reftest-no-accel:
description: "Reftest not accelerated run"
treeherder-symbol: R(Ru)
virtualization: virtual-with-gpu
run-on-projects:
by-test-platform:
windows10.*: []
default: built-projects
chunks:
by-test-platform:
macosx.*: 1
windows.*: 4
linux64(-shippable|-devedition)?/opt: 4
default: 8
mozharness:
chunked:
by-test-platform:
windows10-64.*/opt: false
macosx.*: false
default: true