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
The current setup for bindgen relies on either finding clang/libclang
from the output of llvm-config, or from the paths given via the
configure flags --with-clang-path/--with-libclang-path.
One _very_ common problem is that the llvm-config we end up using does
not correspond to the clang used for compilation, which has some
undesirable side effect, like failing to build.
So instead of relying on llvm-config, we do the following:
- when the compiler is clang, we just use that
- when the compiler is clang-cl, we use clang from the same directory
- otherwise, we either try to find clang in PATH, or rely on
--with-clang-path.
Once clang is found, we try to deduce the location of the corresponding
libclang via the output of `clang -print-search-dirs`, or rely on
--with-libclang-path.
Differential Revision: https://phabricator.services.mozilla.com/D33241
--HG--
extra : moz-landing-system : lando
Changes:
compiled:
- move `cppunit`, `jittest` from `macosx64` to `macosx1014` test set
mochitest:
- move `mochitest-devtools-webreplay`, `mochitest-gpu` to the `macosx1014` test set
Differential Revision: https://phabricator.services.mozilla.com/D33717
--HG--
extra : moz-landing-system : lando
These tasks normally run in 45 to 55 minutes; if they exceed 60 minutes, the
task fails. Failures are not frequent, but I would like to avoid them. We could
increase chunks, but it looks like we have handled the other ccov cases like
this, by increasing the max-run-time.
Differential Revision: https://phabricator.services.mozilla.com/D33656
--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
We would like to switch to using cross-language LTO on all of our
platforms, and we need to use a beta version of Rust on Mac to do that.
Differential Revision: https://phabricator.services.mozilla.com/D33316
--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
