This introduces a toolchain task that just re-exposes the hostutils from
tooltool, which means adding that task as dependency of the relevant
tests gets it automatically. We can then get the hostutils from
MOZ_FETCHES_DIR directly.
Differential Revision: https://phabricator.services.mozilla.com/D205424
In bug 1882100 I updated the nightly-android method to include
ship-geckoview, but in bug 1882083 I'd picked the wrong function to
select android tasks as part of nightly-all, so geckoview ship tasks
went missing.
Remove the duplicate/confusing target_tasks_nightly from
android_taskgraph to prevent something like this happening again.
Differential Revision: https://phabricator.services.mozilla.com/D205330
By setting these to the "build" optimization, it means that bugbug will apply its
machine learning algorithm on autoland and with `mach try auto`.
But in addition, this also sets up some new SCHEDULES rules. A new mutually
exclusive SCHEDULES group around the "application" is created. Namely it can be
one of:
- firefox
- fenix
- focus-android
Files under `/browser` are tagged with the "firefox" component, while files
under `mobile/android` will be tagged with both "fenix" and "focus-android"
components. Files under the `mobile/android/fenix` or
`mobile/android/focus-android` dirs are further restricted to their respective
component. Note that any files that can impact Gecko should not be tagged with
any of these components.
On the task side, all of the prior Firefox builds and tests are tagged with the
"firefox" component, while all of the new Android builds and tests are tagged
with "fenix", "focus-android" or both (depending on the task).
The upshot of all this, is that patches that *only* modify files under
`/mobile/android` will not run any of the Firefox builds and tests. Conversely
patches that *only* modify files under `/browser` will not run any of the
Android builds and tests.
Differential Revision: https://phabricator.services.mozilla.com/D205127
This task checks out the source repository, which can easily take more
than 2 minutes.
It would probably be worthwhile to make it not need that, but this
should do for now.
Differential Revision: https://phabricator.services.mozilla.com/D205245
This patch removes the windows 10 reference hardware talos tests, and removes the platform config for it. With talos tests disabled on the windows10 reference hardware, we can also remove any configuration steps that we have for that platform since there are no other tests running on those machines.
Differential Revision: https://phabricator.services.mozilla.com/D205080
This patch enables motionmark 1.3 on Chrome in CI for the A51 devices as
it was previously on all other apps except for `chrome-m`
Differential Revision: https://phabricator.services.mozilla.com/D204820
This patch removes the windows 10 reference hardware talos tests, and removes the platform config for it. With talos tests disabled on the windows10 reference hardware, we can also remove any configuration steps that we have for that platform since there are no other tests running on those machines.
Differential Revision: https://phabricator.services.mozilla.com/D205080
This patch sets up the scheduling for fenix performance tests on mozilla-central, and autoland. All the same tests will be running across both branches. However, the youtube-playback tests will only be running on mozilla-central. It also removes fenix speedometer tests from the gpt cron since they'll be running on every commit.
Differential Revision: https://phabricator.services.mozilla.com/D202872
This backs out "Bug 1839869 - push fenix/focus nightly to the internal track on
play store.", and reverts to pushing to the default track instead.
Differential Revision: https://phabricator.services.mozilla.com/D204934
Previously we were using `json-automationrelevance` to compute the base_rev.
But recently we improved the Decision task to be smarter about determining
this, so the value already baked into the parameters should be sufficient.
Note that bug 1884386 already removed the transform that was calling
`get_json_automationrelevance`. Rather than re-adding it, this patch uses the
`task_context` transforms to grab the value from parameters instead.
This additionally adds the `--force-local-files-changed` flag to the command,
as we might miss something if we just used the fake values baked into the test
params.
Differential Revision: https://phabricator.services.mozilla.com/D204258
We use hg.m.o's `json-automationrelevance` endpoint for a variety of reasons
such as getting the files changed for optimization purposes, or finding the
base revision for diff purposes. But this endpoint is slow and puts undue load
on hg.mozilla.org if queried too often.
The helper function that fetches this is memoized, so in theory we should only
ever make this request once per graph generation. However, there are still cases
where we request this unnecessarily:
1. When running `./mach taskgraph` locally, we first fetch
`json-automationrelevance` and then fall back to fetching it locally if the
revision wasn't found. I believe the reason for this is to be able to generate
identical graphs as produced by CI.
2. When specifying multiple parameters (so graphs are generated in parallel),
the memoize won't cache across processes, so we make the request once per
parameter set.
3. Any other time we generate tasks outside the context of a Decision task (e.g
`./mach try`), as there are transforms that call this function.
By turning `files_changed` into a parameter, we can ensure that this value gets
"frozen" by the Decision task and it will never need to be recomputed. E.g, you
could use `-p task-id=<decision id>` and you'd still get the `files_changed`
value that Decision task computed. This means, that for all non-Decision use
cases we can rely on local VCS to give us our changed files.
This should greatly cut back on the number of queries being made to `hg.m.o`.
Differential Revision: https://phabricator.services.mozilla.com/D204127
I intially converted this because I was having problems getting 'responses' to
work with the unittest style tests. But then later I ended up not using 'responses'
at all.
Oh well, I think this looks much better anyway.
Differential Revision: https://phabricator.services.mozilla.com/D204126
