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
Created a separate kind for only signing with iscript, and another for notarization.
Once we validate this is good, we need to add it to l10n/emfree/etc and point repackage kind at it.
Differential Revision: https://phabricator.services.mozilla.com/D173967
The kind is more or less the same as the en-US counterpart in the previous revision.
As with the en-US attribution kind, this also does does _not_ use the `multi_dep` loader to set up the per-locale tasks. Of course, we do need to split by locale, which is now being done quite explicitly by the new `split_by_locale` that looks at the specified locales file, and uses specific platforms specified in the kind. As with the previous revision, please feel free to push back if any of you feel any of this is going in the wrong direction, is worse than multi_dep, etc. etc.
Differential Revision: https://phabricator.services.mozilla.com/D170245
Notably, the actual attribution code we're using is stored in `browser`. This was largely motivated by the fact that the subsequent revision in this stack will also need it, and this seemed like the best way to make it shareable between the two. The only alternative I could come up with was stuffing it into a transforms - but it's really just data - there's no reason it ought to live in such a place. (We do have precedent for this sort of thing with both locale and whats new page information, so I don't think it's breaking huge new ground.) Nick - I'm tagging you mainly on this part, but I welcome any other comments you may have (here or in the rest of the stack for that matter).
The other notable part of this patch is that I've _explicitly_ decided not to use the `multi_dep` loader, nor reimplement any of its magic pulling of properties in a transform. I find that this makes it more clear what's _actually_ going on, and easier to debug when making changes. The dwonside, of course, is that there's some verboseness in the kind - all platforms we need to run this for must be explicitly listed. I'm open to debate on whether or not this is the right trade-off, so feel free to push back if you disagree.
Differential Revision: https://phabricator.services.mozilla.com/D170243
There's actually nothing partner-specific in this script, and it's about to be used for other types of attribution as well.
Differential Revision: https://phabricator.services.mozilla.com/D170239
This is a bit more general purpose and flexible than hardcoding `hg-push` here.
It is also something that can be upstreamed to standalone taskgraph.
Differential Revision: https://phabricator.services.mozilla.com/D160536
Also adds docs for how to run the Maintenance Service tests, which is another thing that the --enable-unverified-updates will be useful for.
Differential Revision: https://phabricator.services.mozilla.com/D148870
This patch removes all the code related to the second task (the `*-vismet` tasks) we were using for visual-metrics processing.
Differential Revision: https://phabricator.services.mozilla.com/D142837
The 'release_artifacts' attribute of the Task object doesn't exist in upstream
taskgraph. This attribute is only needed by certain kinds and likely doesn't
belong on the general purpose Task container. Move it to an attribute instead.
This was tested via `taskgraph --diff` on all release tasks. While there is a
diff in that 'release_artifacts' moves from the top-level to under an
attribute, there is no change to the payload of any tasks. So this shouldn't
affect any release graphs.
Depends on D140081
Differential Revision: https://phabricator.services.mozilla.com/D140082
Without this, the desktop nightly graph does not include upload-symbols
tasks for mac, because these tasks don't have the macosx64-shippable
build_platform due to the split x64 / aarch64 build.
Differential Revision: https://phabricator.services.mozilla.com/D139149
