- Incorporated the regular expressions into a list.
- Removed the ^ restriction in the path patterns since it is redundant when using match.
- Added handling of other schemes such as view-source when it preceeds file or http schemes.
- Removed the checking for initial slashes following the url scheme and removed the
requirement for a trailing space.
- Convert test path forward slashes to backslashes in Windows.
Differential Revision: https://phabricator.services.mozilla.com/D35235
--HG--
extra : moz-landing-system : lando
Changes:
- rename the task name from windows10-64-ux to `windows10-64-ref-hw-2017`
- change `hardware` worker type to use the new reference hardware
Differential Revision: https://phabricator.services.mozilla.com/D35262
--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
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
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 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
Bug 1501497 deployed python 3.7 on mac workers, while leaving 3.6
around... except on reimaged workers, which only have 3.7 available.
Differential Revision: https://phabricator.services.mozilla.com/D31191
--HG--
extra : moz-landing-system : lando
Ran locally `./mach taskgraph cron --head-repository=https://hg.mozilla.org/mozilla-central --project=mozilla-central --level=1` and got no errors:
```
0:00.54 using current time for params['time']; try setting $CRON_TIME to a timestamp
0:00.54 calculated cron schedule time is 2019-05-27 09:30:00
0:00.56 not running cron job bouncer-check
0:00.56 not running cron job chromium-update
0:00.56 not running cron job customv8-update
0:00.56 not running cron job nightly-android
0:00.56 not running cron job nightly-desktop
0:00.56 not running cron job nightly-desktop-linux
0:00.56 not running cron job nightly-desktop-osx
0:00.56 not running cron job nightly-desktop-win32
0:00.56 not running cron job nightly-desktop-win64
0:00.56 not running cron job nightly-desktop-win64-aarch64
0:00.56 not running cron job periodic-update
0:00.56 not running cron job pipfile-update
0:00.56 not running cron job searchfox-index
** 0:00.56 not running cron job tp6m-fennec-v64**
```
Feel free to add to this review whoever is relevant.
Differential Revision: https://phabricator.services.mozilla.com/D32674
--HG--
extra : moz-landing-system : lando
The 3-tier PGO builds used a separate mozconfig called 'profile-use' for
the final tier. This created a problem when it rode to beta, since the
same mozconfig was used for all trees, which meant we ended up with
nightly branding on beta builds.
With the PGO-enabling logic in common mozconfigs, we can enable it by
setting the MOZ_PGO_PROFILE_USE environment variable from the task
definition. All of the final-tier PGO builds now use the nightly, beta,
etc mozconfigs like before, so branding should be intact.
Differential Revision: https://phabricator.services.mozilla.com/D33172
--HG--
extra : moz-landing-system : lando
This allows users to set TASKGRAPH_OPTIMIZE_STRATEGIES to a
python_path.find_object string. E.g:
TASKGRAPH_OPTIMIZE_STRATEGIES="module:strategies" ./mach taskgraph optimized
This opens the door to swap in external strategies at runtime and will be
used for back testing experimental strategies.
Differential Revision: https://phabricator.services.mozilla.com/D33203
--HG--
extra : moz-landing-system : lando
Bob Clary
Edwin Gao
Chris AtLee
Wes Kocher
Rok Garbas
Justin Wood
Dorel Luca
Kartikaya Gupta
Sebastian Hengst
Nick Thomas
Simon Fraser
Rob Lemley
Bogdan Tara
Mike Hommey
Byron Campen [:bwc]
Johan Lorenzo
Tom Prince
Mitchell Hentges
alexandru.ionescu
Mike Shal
Andrew Halberstadt
Nick Alexander
Noemi Erli