Before, test.sh (duplicated between the desktop-test and
desktop1604-test images) was dropping permissions, creating a workspace,
and executing test-linux.sh. This is functionality now provided by
run-task.
So, convert the test tasks to use run-task.
One thing run-task isn't doing is created the workspace. So this
functionality has been moved into test-ubuntu1204.sh and
test-ubuntu1604.sh.
Since the test.sh files are no longer used after this change, they have
been deleted. The desktop-test image no longer has any files in the
bin/ directory, so the Dockerfile entry to copy those files has been
removed.
MozReview-Commit-ID: 1BiskrMs6xW
--HG--
extra : rebase_source : 264efc9b30e62927dece848b9b1eab7542cf2cba
extra : source : 8335aa40265b1d17421d06d9e9a180eb8419fe47
extra : histedit_source : a5ae54a810718d446ded8bab510e6cd605562737
Previously, the code performed a "hidden" assignment to
worker['command'] when creating the "command" variable. This
tripped me up when reading the code because relying on variable
references isn't exactly obvious.
We now defer the assignment to worker['command'] until the end,
making the code a little easier to understand.
MozReview-Commit-ID: 23qH4Z3RKY4
--HG--
extra : rebase_source : 52605d7091c73fc47da753bbb298b242f7a3a2ae
extra : histedit_source : 78eb25f963c940956c65fefb2509669a59f78160
Before, test.sh (duplicated between the desktop-test and
desktop1604-test images) was dropping permissions, creating a workspace,
and executing test-linux.sh. This is functionality now provided by
run-task.
So, convert the test tasks to use run-task.
It's worth noting that creating the workspace directory is no longer
necessary because it is defined as a VOLUME in the Dockerfile or a
cache in some task configurations. However, it is default owned by
root:root, so we do need to instruct run-task to chown it.
Since the test.sh files are no longer used after this change, they have
been deleted. The desktop-test image no longer has any files in the
bin/ directory, so the Dockerfile entry to copy those files has been
removed.
MozReview-Commit-ID: 1BiskrMs6xW
--HG--
extra : rebase_source : 4b16837ad9362844668fe4d6cde5ed07a59a3ccd
extra : source : 8335aa40265b1d17421d06d9e9a180eb8419fe47
Before, we'd open files and feed bytes to yaml.load(). When a str
is fed to yaml.load(), it attempts to guess the encoding. It defaults
to UTF-8 unless somebody set us up the BOM. This is probably OK.
Except if the file isn't valid UTF-8, the exception will be raised
in the bowels of YAML parsing and it may not be obvious the failure
is due to invalid UTF-8 input versus say Python str/unicode
coercion foo.
We change all call sites that load YAML from a file to use
codecs.open() to open the file in UTF-8 and perform UTF-8
decoding/validation at file read time. This should make any UTF-8
failures more obvious. Furthermore, it reinforces that our YAML files
are UTF-8 and not some other encoding.
I discovered this issue as part of trying to get emoji symbols to
render on Treeherder. Unfortunately, it appears pyyaml detects
many emoji as unprintable characters and refuses to load them. This
makes me sad and makes me want to abandon pyyaml/YAML in favor of
something that supports emoji :P
MozReview-Commit-ID: AOvAruZFfnK
--HG--
extra : rebase_source : 4c5d42cb63da5c9ebfac55ab84b4f7f8bcc648fa
Before, test.sh (duplicated between the desktop-test and
desktop1604-test images) was dropping permissions, creating a workspace,
and executing test-linux.sh. This is functionality now provided by
run-task.
So, convert the test tasks to use run-task.
One thing run-task isn't doing is created the workspace. So this
functionality has been moved into test-ubuntu1204.sh and
test-ubuntu1604.sh.
Since the test.sh files are no longer used after this change, they have
been deleted. The desktop-test image no longer has any files in the
bin/ directory, so the Dockerfile entry to copy those files has been
removed.
MozReview-Commit-ID: 1BiskrMs6xW
--HG--
extra : rebase_source : 75a937321d1850caebbb1eeaab42d04638ef75d9
extra : source : 8335aa40265b1d17421d06d9e9a180eb8419fe47
Previously, the code performed a "hidden" assignment to
worker['command'] when creating the "command" variable. This
tripped me up when reading the code because relying on variable
references isn't exactly obvious.
We now defer the assignment to worker['command'] until the end,
making the code a little easier to understand.
MozReview-Commit-ID: 23qH4Z3RKY4
--HG--
extra : rebase_source : 44e8a2ddd7b229221d76710c4394618eb13ef348
MozReview-Commit-ID: Lrxi8t53nwy
If a developer adds '--rebuild N' to their try syntax they will get test jobs scheduled N times.
This is useful to determine intermittency rate.
This fixes a regression due to the recent refactoring on how we schedule tasks.
--HG--
extra : rebase_source : 355ca631353015bf63461c194168d753efd6958e
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
Before, we were returning None, which gets converted to 0.
Derp.
Also fix a flake8 failure introduced by 9f5fbb3066c9.
We'll also need to generate a new decision image. But that will
require someone with TC privileges to be around. That can be done
in a separate commit to unblock this from landing and fixing
consumers of run-task that aren't the decision image.
MozReview-Commit-ID: 6XuoIxjDozF
--HG--
extra : amend_source : 4a3047d09d9bdce5a173a71ec3c68b8c4579a910
Before, we were returning None, which gets converted to 0.
Derp.
Also fix a flake8 failure introduced by 9f5fbb3066c9.
We'll also need to generate a new decision image. But that will
require someone with TC privileges to be around. That can be done
in a separate commit to unblock this from landing and fixing
consumers of run-task that aren't the decision image.
MozReview-Commit-ID: 6XuoIxjDozF
--HG--
extra : rebase_source : 836f4996cb9be24e19504f73792b159f0ffbdbee
Until now Gecko decision task artifacts would expire after a week. Unfortunately, some of these artifacts are
needed in order for Treeherder to determine which tasks it can schedule on a given push.
In this change, we're changing the expiration of all artifacts except those that are related to docker image
optimizations, which, are very large files and we only want to keep for a week.
MozReview-Commit-ID: 96ahyWmoI7W
--HG--
extra : rebase_source : d0f4d65e3b5bfae832a5aaed60c0dfd58f0bdc62
I was looking at some decision task logs and noticed lines like:
Connection pool is full, discarding connection: taskcluster
I also noticed lines like:
Starting new HTTP connection (153): taskcluster
In this case, we had established 153 TCP connections to a server.
Looking at the requests source code, a requests.session by default
creates a connection pool with capacity of 10. There are actually 2
components to the capacity: idle connections and active connections.
What appeared to be happening was we could obtain an idle connection,
use it, and then it would be discarded when put back in the idle
pool because the idle pool was at capacity. Furthermore, it also
appears that connections were sitting around waiting for a TCP
connection.
This commit uses a custom "adapter" with an increased pool size that
matches the concurrency level of the code issuing the HTTP requests.
This should increase the number of concurrent TCP connections / requests,
decreease the number of TCP connections being used overall, and make
decision tasks complete faster.
MozReview-Commit-ID: 6NDbz78TM2y
--HG--
extra : rebase_source : a48e1dae31a5e2af2bc554b544a9019d50dc784f
This commit does a lot. But it's really not too difficult to comprehend
once you focus on the final state, which is basically the same as the
"lint" image and derived tasks.
Before, the "decision" image contained a "checkout-gecko" script and
"run-action" and "run-decision" scripts. The latter 2 invoked the first
script.
The "run-task" script basically does what the combination of these
scripts were doing before. So we switch to it.
While we're here, we also replaced the custom Mercurial installation in
this image with the shared install-mercurial.sh script. The
system-setup.sh script for the decision image is now short and sweet.
The YAML files for tasks using this image have been updated to use
"run-task." We no longer have to pass an environment variable to hold
command arguments. So we revert to putting these arguments inline in
the task's command. Dustin never liked passing the arguments as
environment variables, so it should make him happy ;) We add
--log-no-times because "run-task" prefixes its own timestamps on output
lines.
The path to the Gecko checkout has been changed from
/home/worker/workspace to /home/worker/checkouts to match changes made
in bug 1289643.
Finally, since "checkout-gecko-and-run" is no longer used, we delete it.
The Docker image version has been bumped accordingly.
MozReview-Commit-ID: HAGuCz6668Q
--HG--
extra : rebase_source : 9586873c21d67f8ce869b7ceee221e8fa8775539
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
Now that Docker image building is called from Python, we can start to
do advanced stuff with it.
With this commit, we switch from building Docker images directly from
the source directory ("the Docker way") to using our custom Docker image
build contexts.
The main advantage of this is that locally-built Docker images can now
use our custom Dockerfile syntax to include extra files in the build
context!
The code for building a Docker image from a context has been extracted
to its own standalone function. I have nefarious plans for this in the
future, such as the ability to override the FROM syntax to specify
URLs of images. This would allow us to host base images on our own
server, which removes a dependency on Docker Hub and improves
determinism, since images on Docker Hub change all the time.
MozReview-Commit-ID: 5lTdV8yEHkc
--HG--
extra : rebase_source : c374558b82d0d0302351ffbf3c82878c6663f40c
build.sh had been reduced to invoking `docker`. We move that invocation
to Python and remove build.sh. Long live build.sh!
MozReview-Commit-ID: FQBDJv4HSaU
--HG--
extra : rebase_source : 82979f2526ab1ab6dd5c25032b8d81074c797d94
We already had code for resolving the image registry and tag. We
refactored it slightly to be more useful then changed build.sh to
accept the tag as an argument.
At this point, build.sh is basically a wrapper around `docker`. But
there's a special case for executing custom "build.sh" files we
need to eliminate first...
MozReview-Commit-ID: A9HVvxgCdG2
--HG--
extra : rebase_source : 30a408860aea619813f32723fe960d1224b5dbc7
Now that we have a mach command and Python code for doing Docker image
building, we can start moving code from build.sh to Python.
We start with searching for and validating the `docker` binary works.
MozReview-Commit-ID: 2DCc3b8UyZ3
--HG--
extra : rebase_source : ce5ad9dc39eea1fae97aec93eaefbc2c169ec313
extra : amend_source : 806411d3777c657b21d33bbb0e18e06de95716ce
Docker image building will soon need to use Python in order to produce
the image build context archive.
As the first step towards this, we introduce a Python function that
calls out to build.sh. We also implement a mach command that calls it
so we can test the functionality.
I'm not keen about introducing a new mach command. I'd prefer to have
a sub-command instead. I'm not sure what all uses
`mach taskcluster-load-image`. Perhaps we could make a `taskcluster`
top-level command. Or perhaps we could fold these image commands into
`mach taskgraph`? Either way, the mach side of this isn't terribly
important to the commit series: most of the code will live inside a
Python module outside of mach.
MozReview-Commit-ID: AI8p6H4psNh
--HG--
extra : rebase_source : a3a18cbeb05152ab65f2bf152fd2517bbcd8981e
This abstracts out the process of running transforms as specified in kind.yml,
with some useful default behavior that can be overridden by subclasses.
MozReview-Commit-ID: 8pY4IYaN7NU
--HG--
extra : rebase_source : 66711546879edacc5757197674b5bd3f643a0093
extra : source : 9930bede24bcda58c40ca0ee9085aedc00e8ec1b
Previously, the VCS checkout cache would be optimized away on Try. This
meant every task on Try had to create its own checkout from scratch. This
meant writing ~150,000 files. By allowing use of the cache, we minimize
the amount of work tasks need to perform on Try and therefore make tasks
complete faster, on average.
MozReview-Commit-ID: EWuic8lFVtv
--HG--
extra : rebase_source : fd1096da52b499064ab3c0962a4321e8d4f92bb9
All the other expressions are anchored via ^ and $.
MozReview-Commit-ID: BkCbZZUnwK6
--HG--
extra : rebase_source : 0dc6c7577898e447946217494e5cd491b13e22fa
Currently, the gecko-decision and action tasks maintain a separate cache
for each "project" (Firefox repo) source checkout. In my opinion, this
is not necessary.
Separate caches/source checkouts mean a lower chance for a cache hit:
a lower chance that any given worker will have a source checkout readily
available for the "project" being built. They also mean workers store
more data and files in caches.
By using a shared cache for source checkouts, workers will ideally
only have a single source checkout cache and will be pretty much
guaranteed to have a checkout readily available (the main exception
being the first task on a freshly-provisioned worker).
A downside of a shared cache is that workers may spend more time doing
`hg update` operations. e.g. if the last task was from mozilla-release
and the current task is from mozilla-central, thousands of files will
be updated. However, I believe we will still be better off because
separate caches *increase* the probability for a full checkout, which
involves writing ~150,000 files! So I believe this change will lower
the overall amount of VCS work done by workers while possibly
sacrificing the lowest possible execution time (which is achieved by
minimizing the `hg update` work).
It's worth noting that `hg robustcheckout` (which is used by these
tasks) does the equivalent of an `hg purge --all`. This ensures that all
untracked and ignored files from previous tasks are deleted. So there
should be no contamination from previous tasks.
MozReview-Commit-ID: I5Ng3xFEfou
--HG--
extra : rebase_source : db423e5005d1e26d7dfebbbfa28893fc32caef6f
MozReview-Commit-ID: KAqZlUjMXdQ
***
Bug 1289122 - bugfix to chain together the elements to be removed. r=dustin
MozReview-Commit-ID: 3XhHZgmq6e3
--HG--
extra : rebase_source : 2d0ac3710b4ce1376db17a50c6b3bc4354da3ea4
Ryan VanderMeulen
Kim Moir
Andrew Comminos
Wes Kocher
Geoff Brown
Gregory Szorc
Carsten "Tomcat" Book
Dustin J. Mitchell
Sebastian Hengst
Armen Zambrano Gasparnian
Iris Hsiao
Mihai Tabara