gecko-dev/taskcluster/ci/test/web-platform.yml

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

226 lines
7.1 KiB
YAML
Raw Normal View History

# 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 20:44:01 +00:00
suite:
category: web-platform-tests
instance-size: xlarge
max-run-time:
by-test-platform:
android-em-7.0-x86_64/debug: 7200
default: 5400
variants:
by-test-platform:
linux64/debug: ['fission', 'serviceworker']
default: ['fission']
fission-run-on-projects:
by-test-platform:
linux64-qr/debug: ['trunk']
linux64-qr/opt: ['mozilla-central']
windows10-64-qr/opt: ['mozilla-central']
default: []
fission-tier: 2
mozharness:
script: web_platform_tests.py
config:
by-test-platform:
windows.*:
- web_platform_tests/prod_config_windows_taskcluster.py
macosx.*:
- web_platform_tests/prod_config_mac.py
android-em.*:
- android/androidx86_7_0.py
- web_platform_tests/prod_config_android.py
default:
- web_platform_tests/prod_config.py
- remove_executables.py
target:
by-test-platform:
android-em-7.0-x86_64/opt: geckoview-androidTest.apk
android-em-7.0-x86_64/debug: geckoview-androidTest.apk
default: null
web-platform-tests:
description: "Web platform test run"
suite: web-platform-tests
treeherder-symbol: W(wpt)
chunks:
by-test-platform:
android.*: 18
linux64-asan/opt: 24
linux64-ccov/debug: 24
linux64-ccov/opt: 24
linux.*/debug: 18
macosx*/opt: 8
macosx.*/debug: 16
windows.*/debug: 18
windows10-64-ccov/opt: 18
windows10-aarch64/opt: 16
default: 12
max-run-time:
by-test-platform:
.*-ccov/.*: 10800
linux64-qr/debug: 9000
default: 7200
e10s: true
run-on-projects:
by-test-platform:
windows10-aarch64/opt: ['try', 'mozilla-central']
linux1804-32-shippable/opt: ['try', 'release'] # skip integration, Bug 1599197
.*-qr/.*: ['release', 'try'] # skip on integration branches due to high load
default: built-projects
tier:
by-test-platform:
linux64-asan/opt: 2
windows10-aarch64.*: 2
.*-qr/.*: 2 # can't be tier-1 if it's not running on integration branches
linux64-ccov/opt: 3
default: default
mozharness:
chunked: true
extra-options:
- --test-type=testharness
web-platform-tests-reftests:
description: "Web platform 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 20:44:01 +00:00
suite:
name: web-platform-tests-reftests
schedules-component: web-platform-tests-reftests
treeherder-symbol: W(Wr)
virtualization:
by-test-platform:
windows10-64(?:-pgo|-shippable)?-qr/.*: virtual-with-gpu
default: virtual
chunks:
by-test-platform:
.*-ccov/.*: 8
linux1804-64(-qr|-asan)/.*: 6
linux1804-64(-shippable|-devedition)?/opt: 3
macosx10.*-64/debug: 6
windows.*-(32|64)(-qr)?/debug: 5
android.*: 6
default: 4
e10s: true
run-on-projects:
by-test-platform:
windows10-aarch64/opt: ['try', 'mozilla-central']
default: built-projects
tier:
by-test-platform:
linux1804-64-asan/opt: 2
windows10-aarch64.*: 2
default: default
mozharness:
extra-options:
- --test-type=reftest
web-platform-tests-wdspec:
description: "Web platform webdriver-spec 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 20:44:01 +00:00
suite:
name: web-platform-tests-wdspec
schedules-component: web-platform-tests-wdspec
treeherder-symbol: W(Wd)
chunks:
by-test-platform:
.*-ccov/.*: 4
default: 2
mozharness:
extra-options:
- --test-type=wdspec
run-on-projects:
by-test-platform:
windows10-aarch64/opt: ['try', 'mozilla-central']
.*-qr/.*: ['release', 'try']
default: built-projects
tier:
by-test-platform:
android.*: 3
linux64-asan/opt: 2
.*-qr/.*: 2 # can't be tier-1 if it's not running on integration branches
linux64-ccov/opt: 3
default: default
web-platform-tests-wdspec-headless:
description: "Web platform webdriver-spec headless 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 20:44:01 +00:00
suite:
name: web-platform-tests-wdspec
schedules-component: web-platform-tests-wdspec
treeherder-symbol: W(WdH)
chunks: 2
tier: 2
mozharness:
extra-options:
by-test-platform:
windows.*:
- --test-type=wdspec
- --headless
- --headless-width=1600
- --headless-height=1200
default:
- --test-type=wdspec
- --headless
web-platform-tests-crashtests:
description: "Web platform crashtests run"
suite:
name: web-platform-tests-crashtests
schedules-component: web-platform-tests-crashtests
treeherder-symbol: W(Wc)
chunks: 1
mozharness:
extra-options:
- --test-type=crashtest
run-on-projects:
by-test-platform:
windows10-aarch64/opt: ['try', 'mozilla-central']
.*-qr/.*: ['release', 'try']
default: built-projects
tier:
by-test-platform:
linux1804-64-asan/opt: 2
windows10-aarch64.*: 2
.*-qr/.*: 2 # can't be tier-1 if it's not running on integration branches
linux64-ccov/opt: 3
default: default
test-verify-wpt:
description: "Extra verification of web-platform tests modified on this push"
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 20:44:01 +00:00
suite:
category: test-verify
name: test-verify-wpt
variants: []
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 20:44:01 +00:00
schedules-component: test-verify-wpt
treeherder-symbol: TVw
max-run-time: 10800
run-on-projects:
by-test-platform:
# do not run on ccov
.*-ccov/.*: []
.*-asan/.*: []
(?:windows10-64|windows7-32|linux64)(?:-qr)?/opt: ['mozilla-central', 'try']
macosx.*64(?:-qr)?/opt: ['mozilla-central', 'try']
# do not run on beta or release: usually just confirms earlier results
default: ['trunk', 'try']
tier: 2
mozharness:
extra-options:
- --verify
test-coverage-wpt:
description: "Per web-platform test coverage"
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 20:44:01 +00:00
suite:
category: test-coverage
name: test-coverage-wpt
schedules-component: test-coverage-wpt
treeherder-symbol: TCw
max-run-time: 10800
run-on-projects:
by-test-platform:
.*-ccov/.*: built-projects
default: []
tier: 2
mozharness:
extra-options:
- --per-test-coverage