This is a minor refactor that aims to always attempt to set up 'mach' after running the 'run-mozharness' script.
We put it in a 'finally' block so we'll even do this if the user presses Ctrl-C or there was an exception
in the test harness. Importantly, this will be set up regardless of whether the user chooses "Option 1" or
"Option 2" at the wizard prompt.
The reason for this change is mostly 'might as well'. If it can save some users confusion, then it is worthwhile.
MozReview-Commit-ID: Dx3rV17FOoJ
Previously the run-wizard script would add a command to source the virtualenv in ~/.bashrc after
mozharness finished setting things up. This is fragile, assumes people are using bash, etc. Plus
it appeared to intermittently fail for some users.
Instead, this activates the virtualenv directly from individual mach commands that need it. This
guarantees we will always be using the virtualenv if required (and won't be using it if not). The
'activate_this.py' script is invoked the same way that we do it for in-tree mach commands:
https://dxr.mozilla.org/mozilla-central/rev/9c06e744b1befb3a2e2fdac7414ce18220774a1d/python/mozbuild/mozbuild/virtualenv.py#456
MozReview-Commit-ID: CfcoiVJXQTl
332a08725ed0 changed the store path logic in a quick and crude manner.
The code could lead to multiple shared stores existing on a cache
if checkouts were in different parent directories.
This commit refactors the code to explicitly declare a path to the
shared hg store. This restores the behavior of ensuring there is only
a single shared store per cache.
MozReview-Commit-ID: 19Aa1QVrVQ8
We were seeing issues with the Mercurial working directory not being
pristine. While I can't reproduce this, I have a hunch it is due to
mixing and matching stores and checkouts in TaskCluster. For example,
if a worker supports running concurrent tasks and 2 tasks arrive at
the same time, the caches for the store and checkout may look like:
(store0, checkout0)
(store1, checkout1)
However, the next task may get:
(store1, checkout0)
This may confuse Mercurial.
This commit eliminates the "hg-shared" cache and places the shared
stores as a sibling directory of the checkout.
MozReview-Commit-ID: 8SzyS6wWf9C
Robust checkout is the preferred method to clone a mercurial repository. This should
speed up the cloning process a bit and reduce storage size.
MozReview-Commit-ID: 92rcwMwRLYN
There are some packages like 'requests' that are bundled in the mozharness venv, but not in the test
package. It would be easy to manually add these to sys.path in the mach bootstrap script, but it's
much nicer to simply activate this virtualenv in the first place.
MozReview-Commit-ID: 8xeJEIgUbLj
This fixes a race condition between the 'test-linux.sh' process and the 'taskcluster-interactive-shell'
process in interactive tasks.
MozReview-Commit-ID: GhqKpq5pAtj
When running an interactive worker (aka one-click loaner), developers have the option of setting
up the mozharness environment without running tests. When they do this, we should automatically
symlink the mach binary found in the tests.zip to their path. This way developers don't need to
go searching for $HOME/workspace/build/tests/mach to run their tests.
MozReview-Commit-ID: 1JKPYSsYKlN
The run-wizard binary (used by interactive workers) will likely need to
change relatively frequently. Therefore, it should be baked directly into
the docker image. This patch instead downloads it from the appropriate
commit on hg.mozilla.org, only when needed.
MozReview-Commit-ID: 70hlloywCSj
