This patch adds a new backstop optimization strategy for android perf tasks. It will decrease the scheduling frequency of the tests on autoland to about half as often as the original backstop strategy.
Differential Revision: https://phabricator.services.mozilla.com/D217269
This patch adds a lull-schedule attribute to some browsertime live-site tasks so that we can start testing lull-scheduling. The lull-schedule attribute will be used to denote how frequently a particular task should run. The lull-schedule attribute exists first as a raptor specific setting, and is then added to the `extra` section so that we can make use of it in the `mozci` module.
Differential Revision: https://phabricator.services.mozilla.com/D212202
These tasks will never fail, and don't have logs, so having them on
treeherder can be confusing.
Rename `post-signing` to `post-signing-dummy` to benefit from the
special handling in `verify_dependency_tiers`.
Differential Revision: https://phabricator.services.mozilla.com/D211746
This synchronization is now handled in the downstream repositories. In
the case of WebRender by the Servo project and in the case of qcms by a
Gecko-managed GitHub Action. This change removes the github-sync task
from mozilla-central.
Differential Revision: https://phabricator.services.mozilla.com/D204787
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
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
As the motorola G5 and the Pixel 2 have been removed from CI we are also going to remove references to them in our documentation and taskcluster code.
Differential Revision: https://phabricator.services.mozilla.com/D199294
This happened because I made changes to `--target-kind` in upstream Taskgraph,
but forgot to sync the `main.py` bits over to `gecko_taskgraph`.
Differential Revision: https://phabricator.services.mozilla.com/D190807
This results in an identical diff after running:
$ ./mach taskgraph full -p taskcluster/test/params --diff .~1 -J --fast --exclude-key attributes.primary-kind-dependency
Differential Revision: https://phabricator.services.mozilla.com/D181900
Upstream taskgraph removed the special casing of `docker-image` tasks w.r.t
implicitly adding them to the graph, and instead switched over to relying on
the `always_target` feature to accomplish this.
However, in Gecko we usually disable the `always_target` feature entirely (only
enabling it on autoland and try). As a compromise, we implemented a feature in
Taskgraph to allow selectively enabling `always_target` to a specific list of
kinds.
This patch gets Gecko to start using this new feature.
Differential Revision: https://phabricator.services.mozilla.com/D184107
This results in an identical diff after running:
$ ./mach taskgraph full -p taskcluster/test/params --diff .~1 -J --fast --exclude-key attributes.primary-kind-dependency
Differential Revision: https://phabricator.services.mozilla.com/D181900
