Changes:
- migrate jsreftest over to macosx1014
- re-balance the chunks for non-ccov variants of macosx1014
Differential Revision: https://phabricator.services.mozilla.com/D34771
--HG--
extra : moz-landing-system : lando
Changes:
- updated expected outcomes for previously failing tests that now pass on macosx1014
Differential Revision: https://phabricator.services.mozilla.com/D34447
--HG--
extra : moz-landing-system : lando
This drops the --disable-webrender option (which force-disables WR)
and treats the lack of an --enable-webrender as if --disable-webrender
was provided.
Differential Revision: https://phabricator.services.mozilla.com/D34622
--HG--
extra : moz-landing-system : lando
Changes:
- updated expected outcomes for previously failing tests that now pass on macosx1014
Differential Revision: https://phabricator.services.mozilla.com/D34447
--HG--
extra : moz-landing-system : lando
Changes:
- move xpcshell from macosx1010 to macosx1014
- updated regex for macosx1014 xpcshell to run on 2 chunks for all variants (for now)
Differential Revision: https://phabricator.services.mozilla.com/D34561
--HG--
extra : moz-landing-system : lando
Changes:
- added skip-If statements for some crashtest items that fail on macosx1014
- removed `crashtest` from `macosx64` test sets, with the consequence that `macosx64-qr-tests` test set is removed, with cascading effects to the test-platforms definitions that used only `macosx64-qr-tests`
Differential Revision: https://phabricator.services.mozilla.com/D34448
--HG--
extra : moz-landing-system : lando
If the length of the pushes from the pushlog is wrong, raise exception and retry.
Differential Revision: https://phabricator.services.mozilla.com/D34155
--HG--
extra : moz-landing-system : lando
Note that on the bitbar workers we don't get to use a gecko checkout, so
we need to fetch the mozharness.zip and wrench reftests as artifacts from
other jobs.
Differential Revision: https://phabricator.services.mozilla.com/D33409
--HG--
extra : moz-landing-system : lando
Currently all jobs run on bitbar go through mozharness-test. However for
WebRender standalone testing (i.e. built without any Gecko stuff) we want
to run the WebRender wrench test harness on bitbar using run-task. This
adds the necessary support to run-task.
Differential Revision: https://phabricator.services.mozilla.com/D33408
--HG--
extra : moz-landing-system : lando
This is in preparation for having the same script be used for emulator
and device runs. No functional change in this patch; it just renames
the file and class.
Differential Revision: https://phabricator.services.mozilla.com/D33406
--HG--
rename : testing/mozharness/scripts/android_emulator_wrench.py => testing/mozharness/scripts/android_wrench.py
extra : moz-landing-system : lando
This changes the --comm-checkout parameter to the run-task command
to make sure c-c is checked out into a subdirectory of m-c.
Differential Revision: https://phabricator.services.mozilla.com/D34182
--HG--
extra : moz-landing-system : lando
mozharness and mozharness test transforms for generic-worker currently
don't wrap the commands with run-task. This changes things such that the
commands are wrapped with run-task, by piggy-backing on the run_task
transform.
Some things then become redundant with what the run_task transform does,
and some others need to happen later than they currently do in order to
work.
Depends on D28026
Differential Revision: https://phabricator.services.mozilla.com/D28027
--HG--
extra : moz-landing-system : lando
mozharness and mozharness test transforms currently do their own version
of wrapping commands with run-task in docker-worker. This makes them
piggy back on the run_task transform instead.
Some things then become redundant with what the run_task transform does,
and some others need to happen later than they currently do in order to
work.
This has the side effect of enabling some of the more recent run-task
features, like --fetch-hgfingerprint.
Depends on D28025
Differential Revision: https://phabricator.services.mozilla.com/D28026
--HG--
extra : moz-landing-system : lando
The tasks on bitbar currently rely on being run as root, and run-task
defaults to drop its privileges to the `worker` user.
Depends on D28024
Differential Revision: https://phabricator.services.mozilla.com/D28025
--HG--
extra : moz-landing-system : lando
The macos workers have two python 2.7 installed: one in /usr/bin, and
one in /usr/local/bin. For some reason, the one in /usr/local/bin is
broken wrt SSL.
When running the current mozharness command directly without a full path
to python2.7, generic-worker executes it using its own PATH, and that
uses /usr/bin/python2.7. When wrapping with something else, though
(run-task, but that would apply just as much with `sh -c`), the PATH
from the task itself is used, and it's explicitly set to use
/usr/local/bin first, and the broken python 2.7 then gets used.
We could change the PATH, but there might be other things relying on the
current order, so just use /usr/bin/python2.7.
Depends on D28023
Differential Revision: https://phabricator.services.mozilla.com/D28024
--HG--
extra : moz-landing-system : lando
mozharness and mozharness test transforms for generic-worker currently
don't wrap the commands with run-task. This changes things such that the
commands are wrapped with run-task, by piggy-backing on the run_task
transform.
Some things then become redundant with what the run_task transform does,
and some others need to happen later than they currently do in order to
work.
Depends on D28026
Differential Revision: https://phabricator.services.mozilla.com/D28027
--HG--
extra : moz-landing-system : lando
mozharness and mozharness test transforms currently do their own version
of wrapping commands with run-task in docker-worker. This makes them
piggy back on the run_task transform instead.
Some things then become redundant with what the run_task transform does,
and some others need to happen later than they currently do in order to
work.
This has the side effect of enabling some of the more recent run-task
features, like --fetch-hgfingerprint.
Depends on D28025
Differential Revision: https://phabricator.services.mozilla.com/D28026
--HG--
extra : moz-landing-system : lando
The tasks on bitbar currently rely on being run as root, and run-task
defaults to drop its privileges to the `worker` user.
Depends on D28024
Differential Revision: https://phabricator.services.mozilla.com/D28025
--HG--
extra : moz-landing-system : lando
The macos workers have two python 2.7 installed: one in /usr/bin, and
one in /usr/local/bin. For some reason, the one in /usr/local/bin is
broken wrt SSL.
When running the current mozharness command directly without a full path
to python2.7, generic-worker executes it using its own PATH, and that
uses /usr/bin/python2.7. When wrapping with something else, though
(run-task, but that would apply just as much with `sh -c`), the PATH
from the task itself is used, and it's explicitly set to use
/usr/local/bin first, and the broken python 2.7 then gets used.
We could change the PATH, but there might be other things relying on the
current order, so just use /usr/bin/python2.7.
Depends on D28023
Differential Revision: https://phabricator.services.mozilla.com/D28024
--HG--
extra : moz-landing-system : lando
