Considering docker images contents depend very much on the moment they
were built, it is possible that two images with the same hash in the
taskcluster index (at different levels) have different contents. When
this happens, the build or test results could be significantly
different between e.g. try and mozilla-central, possibly leading to
misleading results at landing time.
So if for some reason multiple levels have images for the same hash, the
one used at the highest level should be prefered, such that try uses the
same as mozilla-central once mozilla-central generates the image for
that hash, even if there is an image previously generated for try.
--HG--
extra : rebase_source : 57f593a530da02f9f576872404915c26af544688
We're adding a dummy servo/ports/geckoservo/ directory, which would make
the filtering logic for Taskcluster tasks think that we want to run
Servo tasks all the time. But we don't have a complete installation of
Servo, so things will inevitably fall over if we did that. To avoid
this situation, change the path that the filter checks for to something
a little more specific and less likely to cause conflicts.
This adds `.cron.yml` and a new mach command to interpret it. While
functionality is limited to nightlies right now, there is room to expand to
more diverse periodic tasks. Let your imagination run wild!
MozReview-Commit-ID: KxQkaUbsjQs
--HG--
extra : rebase_source : ddf0a1eadae5a1169c0ead7bcb7b9ce61b255fbf
This adds a HASH file next to the VERSION file in the image
context folders for prebuilt docker images. And uses the
HASH for referencing the image in the tasks created by
the decision task.
This way docker will validate the image hash when pulling it
in production. Thus, attackers won't be able to inject code
by compromising the remote docker registries we use to store
prebuilt images. Further more, this makes validation of the
Chain-Of-Trust artifacts easier as this eliminates the need
for whitelists and hash validation.
MozReview-Commit-ID: FD3B9MyeU9Q
--HG--
extra : rebase_source : e01cdbd0db06b36ba95dec3da936ee307a23aae7
This adds an optional "platforms" key to the job description. It can be used in conjunction with
"by-platform" like so:
platforms:
- linux
- windows
worker-type:
by-platform:
linux: ...
windows: ...
worker:
by-platform:
linux: ...
windows: ...
MozReview-Commit-ID: JwL1NAR4bnY
--HG--
extra : rebase_source : 637dd777912e256d82092ba3e0edd6937cbb03c6
Stylo automation doesn't work unless Servo is present in the source
directory. This commit introduces a "check_servo" filter that prunes
tasks requiring Servo. Currently, this is implemented as a test against
platforms that are unique to Servo.
The use of relative path checking to find the topsrcdir is a bit
unfortunate. But we use this pattern elsewhere in this code.
MozReview-Commit-ID: IRtd53tudJW
--HG--
extra : rebase_source : 8c4742c13878d762fe7970eedfa5937fdaebe8c4
Previously, all callers outside of tests that passed
"target_tasks_method" to TaskGraphGenerator all used the same pattern
of looking for a key in the parameters and calling a function in
the target_tasks module.
Future commits will refactor how target tasks graph work. To
make the transition easier, we move the logic for obtaining the
target tasks method into TaskGraphGenerator.
MozReview-Commit-ID: 3QU09iGhoXh
--HG--
extra : rebase_source : fbcc31d705c4b0e148aa3709ddcb18ad99953231
* Compress docker images with zstd
* Removed need for context.tar from decision task
* Index images by level rather than project
MozReview-Commit-ID: 4RL4QXNWmpd
--HG--
extra : rebase_source : 677d8030a15af3288866a70fc648a10b22c396a3
Often we need to setup a test configuration for different platforms, but
not for different platform builds (opt/debug). This leads to cumbersome
configuration duplicates. This patch adds support for platform regular
expression matching. For example, if you want to configure the chunk
size for linux64 platform both for opt and debug, originally you would
do this:
chunks:
by-test-platform:
linux64/opt: 4
linux64/debug: 4
default: 8
With regular expression matching, you only need:
chunks:
by-test-platform:
linux64/.*: 4
default: 8
This patch was originally written by Geoffrey Brown for Windows support.
MozReview-Commit-ID: KbMHV7UkTLe
--HG--
extra : rebase_source : 79a4344c7e3e978bb6b93713c6e6e4114ba5d5b8
The `from_parameters` method was never used, and let do confusion over the role
of these parameters. Now there are only two, and they are always required.
MozReview-Commit-ID: AbPqijXucu5
--HG--
extra : rebase_source : 85affd063a543c549afaaa36ce7ee31ed1f943d5
Often we need to setup a test configuration for different platforms, but
not for different platform builds (opt/debug). This leads to cumbersome
configuration duplicates. This patch adds support for platform regular
expression matching. For example, if you want to configure the chunk
size for linux64 platform both for opt and debug, originally you would
do this:
chunks:
by-test-platform:
linux64/opt: 4
linux64/debug: 4
default: 8
With regular expression matching, you only need:
chunks:
by-test-platform:
linux64/.*: 4
default: 8
This patch was originally written by Geoffrey Brown for Windows support.
MozReview-Commit-ID: HFP52N9Ef0k
--HG--
extra : rebase_source : d2a5129b7459fc7f71f59da76d45526cef028e44
If you want to run tests on Linux32 and Linux64, you use trychooser syntax like
"-u all[Ubuntu]" which taskcluster supports, but if you also built ASan, and
want tests on ASan, there's no supported documented way to get them. That sounds
like an edge-case, except that to get tests to run on WinXP or Win8 you have to
explicitly list them, so to get tests on every platform you build you have to
list all of them, and if ASan is one of them you have to somehow know to dig
around in the .yml and to know that linux64-asan is the thing to dig out.
MozReview-Commit-ID: 2REf0cUWmK8
--HG--
extra : rebase_source : cb77ff3e016939c94ac05964a6db809fe10aaa1a
In this case, the tasks must have the same schedulerId as the existing task,
so this is calculated using parameters['level'].
MozReview-Commit-ID: G8EE2kvFstT
--HG--
extra : rebase_source : 214885da9b58520727d5f80b9a31bb8a206f9279
This uses the run_on_projects attribute introduced earlier for most branches,
adjusts the `ash` method to handle that branch as the legacy implementation
did, and updates try syntax to match builds as well as tests.
In the process, this enables optimizing target tasks, meaning that tasks
specifically requested in the try syntax might be optimized. While this is
probably not ideal, it matches the existing behavior of try (where `-j all` is
the default but all jobs are set to run only when certain files have been
modified). This change can be reverted later, in a more advanced version of
try.
MozReview-Commit-ID: 5FYeUTAsafr
--HG--
extra : rebase_source : b358e0e7cd8a401c50009e63dd55c59489c9b75b
MikeLing initially did this in bug 1287018. The intent of this conditional was
to make optimization faster by not even checking most tasks, based on the
assumption that if the prerequisite to a task has changed (for example, a
docker image or a build), then naturally we will want to execute that task.
However, as we have developed actual optimization methods, this has proven not
to be the case: we might want to optimize a test out if its inputs have not
changed, even if a new installer has been built. Similarly, SETA may optimize
tasks out even if their inputs have changed.
MozReview-Commit-ID: LgHET3Z84GB
--HG--
extra : rebase_source : efd297d37bd49dbe655266380641abc258dda725
Without this, current umask may influence test results. That was
causing differences between automation and local runs.
MozReview-Commit-ID: 1eu613aBpKB
--HG--
extra : rebase_source : 41c92b9ea795217e715dfa949d3444534aafb7c7
Use the source RIDEALONG_BUILDS value in the module under test so that changes
to that variable do not cause the test to fail.
MozReview-Commit-ID: EfHQ7baBziB
--HG--
extra : rebase_source : 1c52bf62709236db14a3ce318495891a2eb274f4
The existing hash was for an empty tarfile. Oops!
MozReview-Commit-ID: 1KOZxnDmoOH
--HG--
extra : rebase_source : 5d4db299dba80f98ba0383e88a1f4cfcb1dbcc70
The function was only used once and was providing little to no value.
A test of this function has been removed. Tests for the lower-level
context creation function are sufficient.
MozReview-Commit-ID: D9EhmZQlqG5
--HG--
extra : rebase_source : 4b3faa0fc5f085c1c77fe5636744946a6d442b05
A limitation of traditional docker build context generation is it
only includes files from the same directory as the Dockerfile. When
repositories have multiple, related Dockerfiles, this limitation
results file duplication or putting all Dockerfiles in the same
directory (which isn't feasible for mozilla-central since they would
need to be in the root directory).
This commit enhances Dockerfiles to allow *any* file from the
repository checkout to be ADDed to the docker build context.
Using the syntax "# %include <path>" you are able to include paths
or directories (relative from the top source directory root) in the
generated context archive. Files add this way are available under the
"topsrcdir/" path and can be ADDed to Docker images.
Since context archive generation is deterministic and the hash of
the resulting archive is used to determine when images need to be
rebuilt, any extra included file that changes will change the hash
of the context archive and force image regeneration.
Basic tests for the new feature have been added.
MozReview-Commit-ID: 4hPZesJuGQV
--HG--
extra : rebase_source : 99fae9fe82102126fbee879c134981047bb4a601
This restores order to only having a single hash for a context
directory.
Using a tempfile here is a bit unfortunate. It can be optimized later,
if needed.
MozReview-Commit-ID: LMNsvt3fDYx
--HG--
extra : rebase_source : 8c2b70164aed6d744a71d170d0324797e755cbaf
Now that the context tar creation function is standalone and doesn't
rely on external state, we can start unit testing it easier.
We establish a basic unit test that verifies the function works as
advertised and that output is deterministic.
MozReview-Commit-ID: H4MY28PiHSN
--HG--
extra : rebase_source : 692a5e3d5af6edd14b3d4ceb7c90cd1e0344052f
This introduces a completely new way of specifying test task in-tree,
completely replacing the old spider-web of YAML files.
The high-level view is this:
- some configuration files are used to determine which test suites to run
for each test platform, and against which build platforms
- each test suite is then represented by a dictionary, and modified by a
sequence of transforms, duplicating as necessary (e.g., chunks), until
it becomes a task definition
The transforms allow sufficient generality to support just about any desired
configuration, with the advantage that common configurations are "easy" while
unusual configurations are supported but notable for their oddness (they
require a custom transform).
As of this commit, this system produces the same set of test graphs as the
existing YAML, modulo:
- extra.treeherder.groupName -- this was not consistent in the YAML
- extra.treeherder.build -- this is ignored by taskcluster-treeherder anyway
- mozharness command argument order
- boolean True values for environment variables are now the string "true"
- metadata -- this is now much more consistent, with task name being the label
Testing of this commit demonstrates that it produces the same set of test tasks for
the following projects (those which had special cases defined in the YAML):
- autoland
- ash (*)
- willow
- mozilla-inbound
- mozilla-central
- try:
-b do -p all -t all -u all
-b d -p linux64,linux64-asan -u reftest -t none
-b d -p linux64,linux64-asan -u reftest[x64] -t none[x64]
(*) this patch omits the linux64/debug tc-M-e10s(dt) test, which is enabled on
ash; ash will require a small changeset to re-enable this test.
IGNORE BAD COMMIT MESSAGES (because the hook flags try syntax!)
MozReview-Commit-ID: G34dg9f17Hq
--HG--
rename : taskcluster/taskgraph/kind/base.py => taskcluster/taskgraph/task/base.py
rename : taskcluster/taskgraph/kind/docker_image.py => taskcluster/taskgraph/task/docker_image.py
rename : taskcluster/taskgraph/kind/legacy.py => taskcluster/taskgraph/task/legacy.py
extra : rebase_source : 03e70902c2d3a297eb9e3ce852f8737c2550d5a6
extra : histedit_source : d4d9f4b192605af21f41d83495fc3c923759c3cb
This enables kinds that generate tasks based on those output by another kind.
For example, the test kind might generate a set of test tasks for each build
task.
MozReview-Commit-ID: K7ha9OmJ6gd
--HG--
extra : rebase_source : 36fc7e2d9c5987a4bb8b3779cf1a9308f5561828
extra : intermediate-source : 7898d1ab1afc08f78445165d0c94566b0682a2f7
extra : source : 0852b38cd86c42ebba0f9e74d7470a263969b784
