The code that actually downloads it is behind a condition that isn't set
anywhere.
Differential Revision: https://phabricator.services.mozilla.com/D24215
--HG--
extra : moz-landing-system : lando
Currently, if the files match and you try to look at the diff, you get
{
"reason": "file-missing-on-worker",
"message": "Artifact \"public/diff.html\" not found at \"/builds/worker/diff.html\""
}
which makes it hard to tell if there was an error generating a diff, or if the files matched.
This changes things to ask diffoscope to always output a diff, to remedy that confusion.
Differential Revision: https://phabricator.services.mozilla.com/D24316
--HG--
extra : moz-landing-system : lando
Searchfox relies on the bugzilla component job running on the same push
as the indexing jobs, but there's nothing that actually guarantees that.
Thus far pushes to m-c pretty much always have source changes so the
bugzilla component job gets run, but on beta/release branches it's
possible to get pushes with just tag changes and no source changes, so
the bugzilla component job would get optimized away. This patch ensures
that the job gets run along with the other indexing jobs that searchfox
needs.
Differential Revision: https://phabricator.services.mozilla.com/D24507
--HG--
extra : moz-landing-system : lando
Without this the shippable builds take >20 seconds to compute the prune through new_as_old_is_high_value, locally. With this it is near instant.
Differential Revision: https://phabricator.services.mozilla.com/D22711
--HG--
extra : moz-landing-system : lando
This sets all of the shippable tests to not run in the places where they would otherwise.
This patch will be effectively undone later in the patchset.
Differential Revision: https://phabricator.services.mozilla.com/D22710
--HG--
extra : moz-landing-system : lando
When we set the nightly attribute the tasks don't run on-push, so we use a new attribute.
Differential Revision: https://phabricator.services.mozilla.com/D22709
--HG--
extra : moz-landing-system : lando
This commit adds a new build for OSX since there is no current PGO build type for OSX.
And calls it shippable, this mirrors that of the nightly.
Differential Revision: https://phabricator.services.mozilla.com/D22225
--HG--
extra : moz-landing-system : lando
This was needed since when we have job-defaults and later on a test set for
``
run-on-projects:
by-test-platform:
...
``
We were ending up with both the list of by-* being extended but also
any array in that list also being extended (like `default: ['a', 'b']`
was getting extended to also have the new values for default)
This is not only usually wrong but very very likely not what the author wanted.
Differential Revision: https://phabricator.services.mozilla.com/D22708
--HG--
extra : moz-landing-system : lando
Bug 1534522 added win64-aarch64-eme/opt builds, which are artifact builds
that glue together a win64-aarch64/opt build and a win32/opt build.
This enables EME on the corresponding nightlies in a slightly different
way:
- this adds a no-eme build that corresponds to win64-aarch64/opt.
- this turns the existing nightly into an artifact build that glues
together that no-eme build and the win32 nightly.
The no-eme build cannot have the nightly attribute set, first because
the beetmover transform fails in that case, and because that would imply
shipping those builds, but they're not meant to be shipped this way.
It also has run-on-projects set to an empty list so that it doesn't
appear by default in `mach try fuzzy`, while still being triggered when
needed due to being a dependency of the nightly build.
It is preferable to keep the win64-aarch64{,-eme}/opt builds untouched
to make things easier for try (the win64-aarch64 ones being the main
ones to try; also, the -eme builds currently fail with --artifacts).
Ideally, like in bug 1534522, we'd add a diffoscope build to ensure
the variations between the nightly and its base no-eme build are within
control, but currently, that would trigger nightlies on every push,
which is not desirable. Ideally, they'd trigger whenever both their
dependencies are in the target task graph. We leave that to a followup.
Differential Revision: https://phabricator.services.mozilla.com/D23640
This introduces a mozharness script, android_emulator_pgo.py, to run the
profileserver suite with the PGO-instrumented Android build, and collect
the profile data and jarlog.
The mozharness script contains some redundancy with
build/pgo/profileserver.py, but the additional requirements for Android
to use adb and existing mozharness classes to control the emulator made
it difficult to share the desktop profileserver implementation.
Differential Revision: https://phabricator.services.mozilla.com/D22825
--HG--
extra : moz-landing-system : lando
This is the first stage of the Android PGO task pipeline to generate an
instrumented build.
Differential Revision: https://phabricator.services.mozilla.com/D22824
--HG--
extra : moz-landing-system : lando
The mozharness.py transform passes in "options" parameters through the
MOZHARNESS_OPTIONS environment variable. This will allow the Android PGO
run task to pass in the mozharness script name to test-linux.sh
Differential Revision: https://phabricator.services.mozilla.com/D22822
--HG--
extra : moz-landing-system : lando
In order to call test-linux.sh with the job-script parameter, it needs
to have executable permissions.
Differential Revision: https://phabricator.services.mozilla.com/D22821
--HG--
extra : moz-landing-system : lando
test-linux.sh defaults to true for NEED_XVFB, while build-linux.sh
defaults to false. If we are using test-linux.sh from mozharness (rather
than mozharness-test), we need to explicitly set NEED_XVFB to false in
order to not use xvfb.
Differential Revision: https://phabricator.services.mozilla.com/D22820
--HG--
extra : moz-landing-system : lando
This adds worker-type alias that has dedicated workers at level-3 for running
instrumented builds, but uses a test worker type at other levels.
Differential Revision: https://phabricator.services.mozilla.com/D23576
--HG--
extra : moz-landing-system : lando
There are a number of ways we want to vary workers over time and jobs, including
- we are working on migrating to gce
- pgo builds have a dedicated worker-type for running the instrumented build
at level 3 but not level 1
Rather than have all tasks know about how the machines are provisioned, this
moves to using short-names for the worker types, and then has a config mapping
those to the actual worker types.
This adds support for aliases, and an initial set of them. Follow up work will
switch the existing uses of these worker types to using the aliases.
Differential Revision: https://phabricator.services.mozilla.com/D22549
--HG--
extra : moz-landing-system : lando
comm-task-env runs before run-task and updates the environment with GECKO_*
variables that are defined in a file at the root of a subproject's repository,
such as "comm-central".
Updates:
- add comm-task-env
- add python 3.5 (run-task dependency)
- add pyyaml
Differential Revision: https://phabricator.services.mozilla.com/D16934
--HG--
extra : moz-landing-system : lando
comm-task-env runs before run-task and updates the environment with GECKO_*
variables that are defined in a file at the root of the comm repository,
".gecko_rev.yml". run-task needs these variables to be set to find the
correct mozilla repository to check out for a particular TB build.
The current pinning method of updating ".taskcluster.yml" with the mozilla
repository and revision to pin tois no longer supported.
Differential Revision: https://phabricator.services.mozilla.com/D16783
--HG--
extra : moz-landing-system : lando
