When iterating on taskgraph changes, the exact number of chunks that
test-verify runs usually isn't important, so skip it when going fast.
Differential Revision: https://phabricator.services.mozilla.com/D2730
--HG--
extra : rebase_source : 4d46eee982e9868050f1201aba74b020045d9ec1
extra : histedit_source : 744948fa80ae8e3b18212e840843906577fd38ec
The taskgraph code for test-verify currently looks at locally changed files to
determine how many chunks should be run. This code exists so that
`mach try fuzzy` show the same chunks that would be run on a try push.
This changes it, so that local commts are only considered on try and when
called from try-select. This makes generating the taskgraph locally faster,
when not using `mach try`. It also makes test-verfiy not consider too many
files, if the try push happens to contain commits that have landed but havent
been pushed to try yet (i.e. the first push to try after a merge, or beta try
pushes).
Differential Revision: https://phabricator.services.mozilla.com/D2698
--HG--
extra : rebase_source : 68b1ea583730ff3086949aa6c7b6a1046b406d23
extra : histedit_source : 68bbc7ca2062c7f425353e6caf6b8959786dc42d
Currently, `mach try fuzzy` generates a taskgraph that is configured exactly
like the most recent push to mozilla-central. This isn't always desirabe, so
pass some configuration down, to allow the taskgraph to behave differently.
Differential Revision: https://phabricator.services.mozilla.com/D2729
--HG--
extra : rebase_source : 99d6958b33211697227e65df17edc1eb337f63a4
extra : histedit_source : 69b5ff6805bc8409340eb71323a1f6fc637259d7
Enables the benchmark in CI, uses a fetch task to download the benchmark.
Depends on D2307.
Differential Revision: https://phabricator.services.mozilla.com/D2469
--HG--
extra : moz-landing-system : lando
This will apply to cron tasks, action tasks, and decision tasks. It is a
distinct retrigger implementation because (a) we do not want to follow
dependencies, and (b) it takes a lot of scopes to create a decision task, so we
need to limit access to this action.
MozReview-Commit-ID: 21DVSiagcrO
--HG--
extra : rebase_source : 6f027e349e245e4aa4dbed81145a0a5d75218cb1
extra : histedit_source : eff99aee5a0e7496b0734748b29739480eb0e3fb
This additionally reconsiders the order of all of the actions, spacing them 50
"units" apart and putting the more common actions first.
MozReview-Commit-ID: 98IOYKVMcGU
--HG--
extra : rebase_source : 1273a8b86625bd8e4dc3bddab80c6912241f88c8
extra : histedit_source : 16314284a2b4e0368da843b036e22aaedf485307
This removes the 'use-artifacts' mechanism in favour of fetches. There are a
few pieces here that need to land atomically:
1. Remove use-artifact related code
2. Call 'fetch-content' from the run-task script
3. Convert existing tasks on top of fetches (jsshell, python unittest)
4. Stop calling 'fetch-content' from toolchain setup tasks (as this now gets handled in run-task)
Depends on D2166.
Differential Revision: https://phabricator.services.mozilla.com/D2167
--HG--
extra : moz-landing-system : lando
This removes the 'use-artifacts' mechanism in favour of fetches. There are a
few pieces here that need to land atomically:
1. Remove use-artifact related code
2. Call 'fetch-content' from the run-task script
3. Convert existing tasks on top of fetches (jsshell, python unittest)
4. Stop calling 'fetch-content' from toolchain setup tasks (as this now gets handled in run-task)
Depends on D2166.
Differential Revision: https://phabricator.services.mozilla.com/D2167
--HG--
extra : moz-landing-system : lando
Currently 'fetch' artifacts are all extracted in the same directory, this could
make the extdir messy, or in the worst case, cause file name collisions.
Some artifacts are ok to extract into the same directory as they're already
bundled within the archive. But other artifacts are not. This patch keeps the
default behaviour (extracting everything into the same directory), but allows
task authors to specify per-artifact directories to extract into.
The syntax is:
path[>dest]@<task>
The 'dest' value will be a subdirectory of the MOZ_FETCHES_DIR environment
variable.
Depends on D2102.
Differential Revision: https://phabricator.services.mozilla.com/D2166
--HG--
extra : moz-landing-system : lando
Fetches no longer need to be artifacts exposed via a 'fetch' task, they can
also be artifacts from a task's dependencies. The new format is:
fetches:
fetch:
- fetch-artifact-1.zip
- fetch-artifact-2.zip
build:
- build-artifact-1.zip
...
Specifying 'build' artifacts to fetch will error out if the task doesn't have
any build dependencies.
The 'fetch' key works the same as before, but it is now a special case. Unlike
'build' (or other dependencies), adding a fetch task's artifact here will
implicitly make our task depend on the corresponding fetch task. It will not
be an error.
Depends on D2028.
Differential Revision: https://phabricator.services.mozilla.com/D2102
--HG--
extra : moz-landing-system : lando
Fetches no longer need to be artifacts exposed via a 'fetch' task, they can
also be artifacts from a task's dependencies. The new format is:
fetches:
fetch:
- fetch-artifact-1.zip
- fetch-artifact-2.zip
build:
- build-artifact-1.zip
...
Specifying 'build' artifacts to fetch will error out if the task doesn't have
any build dependencies.
The 'fetch' key works the same as before, but it is now a special case. Unlike
'build' (or other dependencies), adding a fetch task's artifact here will
implicitly make our task depend on the corresponding fetch task. It will not
be an error.
Depends on D2028.
Differential Revision: https://phabricator.services.mozilla.com/D2102
--HG--
extra : moz-landing-system : lando
The 'use_fetches' transform is currently only being used by toolchain tasks,
but we'd like to expand this to more kinds (like 'test' and 'source_test').
The problem is that 'use_fetches' doesn't have a schema, and assumes things
about the kinds of keys that will be set in the job. For example, it assumes
that job['worker']['env'] is going to be forwarded up to the jobdesc properly.
By moving this transform into the set applied to all 'job' tasks, we:
A) Have a task schema we can reliably depend on
B) Can automatically use it from any 'job' task without kind specific
modifications
Since the toolchain tasks apply the 'job' transforms (almost) right after
the 'use_fetches' transform, this change just works.
Differential Revision: https://phabricator.services.mozilla.com/D2028
--HG--
extra : moz-landing-system : lando
This patch makes the QR test platforms tier-1 by default, and removes
the ad-hoc bits that were making individual QR jobs tier-1 before.
However, it also explicitly downgrades some QR jobs to tier-2 or tier-3;
comments in the yml files indicate why.
MozReview-Commit-ID: 1UfPuhcMvIW
--HG--
extra : rebase_source : a2347f6a5929246aaba7656b59c0b8f7aa4ca081
This is needed to not have a circular kind dependency when we actually spell out all dependencies (in a following patch)
Differential Revision: https://phabricator.services.mozilla.com/D1695
--HG--
rename : taskcluster/ci/repackage-signing/kind.yml => taskcluster/ci/repackage-signing-l10n/kind.yml
extra : rebase_source : c2998ba23f213090d27495eb44c3bde3a1628dff
Test verification backfill specifies --gpu-required for certain types
of tests (depending on test path and/or suite). web-platform-tests do
not recognize --gpu-required. This patch updates the backfill logic
to avoid --gpu-required for wpt.
The actionPerm is for access control, so it must limit access to a specific
callback function, not a name (which can apply to mulitple functions).
To make things nicer, we allow functions to specify their cb_name and default
it to the action name. The decorated function names are not used.
MozReview-Commit-ID: 2oiuXrrw7DE
--HG--
extra : rebase_source : 07b27db25e9c8e3226dc996d3fcef401ca498739
Everything but release-promotion (to be handled in another bug) is generic.
For the moment, these all run with the default repo scopes; once this is
landed, I can start adjusting that and granting the necessary scopes only to
these actions.
MozReview-Commit-ID: IB8OEsfeBpj
--HG--
extra : rebase_source : 6ef1697cf255b579097ef8b85be8f9f62718f548
This carefully maintains tasks as an array by putting the conditional inside of
that array. Note that `[{$if: 'false', then: 1}]` returns `[]` in JSON-e --
the missing `else` branch is treated as a missing array element.
MozReview-Commit-ID: 9ARIxW3gfWo
--HG--
extra : rebase_source : 304ce14ccc9abc9f4f48f3179adb981b5fe55a0e
This changes
File "/builds/worker/checkouts/gecko/taskcluster/taskgraph/actions/cancel_all.py", line 30, in list_group
for task in [t['status'] for t in response['tasks']]:
KeyError: u'tasks'
Into a more understandable error (404, in this case).
MozReview-Commit-ID: 5XnFyxIdRfo
--HG--
extra : rebase_source : 797a3117d3246c962f30980c1658fde3bd366135
This also updates actions to "see through" the conditional. Soon we won't be
using kind=task, so this hack will be less important.
MozReview-Commit-ID: Aa6g9ZqoPMa
--HG--
extra : rebase_source : 7434f2047c48ff0d1fa6de9e3419fb4e0bf0bb72
The resulting action task isn't useful to the user, so instead we send an email
containing a link to the interaction console.
MozReview-Commit-ID: 5uHnQo9WTF6
--HG--
extra : rebase_source : ec52a333582a2778c2cec12d612d681e1a9b1976
The resulting action task isn't useful to the user, so instead we send an email
containing a link to the interaction console.
MozReview-Commit-ID: 5uHnQo9WTF6
--HG--
extra : rebase_source : 1213afa7c53a0bcc4a07c4c2970c7bf21ab3b7f1
Also include webgl2-deqp, which we would like to run eventually, but not yet.
MozReview-Commit-ID: CY4hYCI95ws
--HG--
extra : rebase_source : 9973df0f905bb65d2e8b8c66a6a57e8869e527c1
Also include webgl2-deqp, which we would like to run eventually, but not yet.
MozReview-Commit-ID: FDWdu1J0end
--HG--
extra : rebase_source : a47d88cb2c5eb82e4dfaa9e58d76acbf0736d35d
This will make sure that when running |mach python-test --python 3| locally,
we only run the tests that also run in CI with python 3 (and therefore pass
presumably).
MozReview-Commit-ID: 3OBr9yLSlSq
--HG--
extra : rebase_source : 456340d0ecdddf1078f2b5b4ebb1eddf3813b26a
Assorted fixes from trawling the sphinx logs - malformed formatting, broken references, leftovers from renaming action-task to action-callback and removing
yaml-templates, docstring fixes to make sphinx happier, and typos.
MozReview-Commit-ID: 6jUOljdLoE2
--HG--
extra : rebase_source : f2a9dbcde5180f760a80f47691a70eba76e58bad
Various fixes for the docs to make docs better and sphinx happier
* remove unused targets which were duplicated in balrog, partials
* fix up malformed targets and links
* convert docstrings to comments so sphinx ignores example response in utils/partials.py
* section underlines should match titles
MozReview-Commit-ID: GSYqsocBC4I
--HG--
extra : source : e464e9bbb42fb85170f1ce35a01f25811d753871
We shouldn't run this on central, as it falls back to the dev configs, and fails.
It should be fine on beta/release/esr60. I had to move this version of the check to its own
kind to avoid the dependency tree bringing in the entire build process. Perhaps we can
refactor later to avoid duplication
Differential Revision: https://phabricator.services.mozilla.com/D1765
--HG--
rename : taskcluster/ci/release-bouncer-check/kind.yml => taskcluster/ci/bouncer-check/kind.yml
yaml.load() can evaluate arbitrary Python code via syntax such as
`!!python/object/apply:os.system`. Seriously.
Let's switch taskgraph to yaml.safe_load(), which is reasonable
about limiting magic.
Differential Revision: https://phabricator.services.mozilla.com/D1736
Any run-task task could exit with EXIT_PURGE_CACHES and expect the
task to be retried. Before this commit, we only registered this exit
code for tasks "using: run-task." That excluded mozharness and
a handful of other "using" flavors.
With this commit, we register the exit codes for all run-task tasks
by sniffing for the presence of run-task in the low-level code that
emits the task definition. This should prevent run-tasks tasks
from falling through the cracks and not having their exit codes
result in meaningful behavior.
Differential Revision: https://phabricator.services.mozilla.com/D1715
