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
This typically shouldn't happen because both the try push and Decision task are
generating the graph based off the same revision. But one scenario it's
possible is if the local graph was loaded from cache and there are invalidation
bugs.
A known invalidation bug can happen when a variant expires in-between when a
cached graph was saved and loaded.
Differential Revision: https://phabricator.services.mozilla.com/D203282
We should use the default here, which includes `docker-image`, otherwise the
`add_index_tasks` morph can fail. This parameter is already special-cased for
the esr115 params files in the update script from bug 1850914, but
mb-ship-geckoview.yml wasn't updated.
Differential Revision: https://phabricator.services.mozilla.com/D199886
The target_tasks methods for ship_geckoview and nightly_desktop return
an empty graph when running on automation if they detect a taskcluster
index from a previous run on the same revision. This wasn't a problem
with old parameters since the corresponding indexed tasks are expired,
but with updated parameters it starts triggering. We don't want that
logic here, since we're asserting we get a nonempty graph.
Differential Revision: https://phabricator.services.mozilla.com/D194523
If called with no arguments it'll update all files (except try.yml and
mr-onpush-geckoview.yml). It can also be called with a set of filenames
as arguments and will update just those files.
For on-push and cron tasks, we look up the taskcluster index for the
latest corresponding decision task (or possibly an older one in case of
DONTBUILD pushes). For release promotion actions, we query the public
shipit API to find the latest matching task.
Differential Revision: https://phabricator.services.mozilla.com/D187137
If called with no arguments it'll update all files (except try.yml and
mr-onpush-geckoview.yml). It can also be called with a set of filenames
as arguments and will update just those files.
For on-push and cron tasks, we look up the taskcluster index for the
latest corresponding decision task. For release promotion actions, we
query the public shipit API to find the latest matching task.
Differential Revision: https://phabricator.services.mozilla.com/D187137
If called with no arguments it'll update all files (except try.yml and
mr-onpush-geckoview.yml). It can also be called with a set of filenames
as arguments and will update just those files.
For on-push and cron tasks, we look up the taskcluster index for the
latest corresponding decision task. For release promotion actions, we
query the public shipit API to find the latest matching task.
Differential Revision: https://phabricator.services.mozilla.com/D187137
