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

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

189 строки
5.4 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: ['serviceworker']
default: []
run-on-projects:
by-test-platform:
android-em-4.3-arm7-api-16/opt: ['try']
windows10-aarch64/opt: ['try', 'mozilla-central']
default: built-projects
mozharness:
script:
by-test-platform:
android-em.*: android_emulator_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
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.3-arm7-api-16/debug: 10
android-em-4.3-arm7-api-16/opt: 4
android-em-4.3-arm7-api-16/pgo: 4
android-em-7.*: 1
default: 1
e10s:
by-test-platform:
linux32/debug: both
default: true
max-run-time:
by-test-platform:
android-em.*: 7200
default: 3600
tier:
by-test-platform:
windows10-aarch64.*: 2
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:
by-test-platform:
android-em.*: xlarge
default: default
chunks:
by-test-platform:
android-em-4.3-arm7-api-16/debug: 100
android-em-7.0-x86_64/opt: 4
android-em-7.0-x86_64/debug: 8
android-em.*: 40
windows.*: 2
windows10-64-ccov/debug: 5
linux64-ccov/.*: 5
linux64-qr/opt: 4
linux64-qr/debug: 5
linux32/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
default: default
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.3-arm7-api-16/debug: 56
android-em-4.*: 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:
by-test-platform:
linux32/debug: both
default: 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