Currently make check loops over all directories and runs each test file in PYTHON_UNIT_TESTS
individually. This patch instead creates a single top-level check target that runs
|mach python-tests|. This should make automation more similar to running locally, be a bit
quicker and make it easier to pull python tests out of make check completely at a future date.
MozReview-Commit-ID: 4Hg4zdFyc61
--HG--
extra : rebase_source : 31d0c38a76c11b75d3bf569f2bf22a0666161726
Now, NativeKey respects following WM_CHAR message. Therefore, we can create a test for bug 1293505 which a function key causes a printable character.
Additionally, bug 1307703 is now fixed by the previous patch. So, let's add automated test for it too.
Finally, now, I found a way to test with some keyboard layouts which are not available on old Windows. Therefore, we should add automated tests for bug 1297985 too.
MozReview-Commit-ID: IqCEPbPYrcQ
--HG--
extra : rebase_source : 451d0264f1180cae7d7035a498f1c13416d53246
It will pass once we re-sync from upstream, as the upstream test matches the
specified behaviour, whereas this test does not.
MozReview-Commit-ID: J16olE6QgP
--HG--
extra : rebase_source : 2df77567bfb31c5345627c551cfdcd8b14925ca9
Rather than clearing actions in volatile_config, add in actions from the artifact config's
default_actions. Incompatible actions are then skipped based on 'forced_artifact_build'
config value.
MozReview-Commit-ID: IZuDvxcQ7cN
--HG--
extra : rebase_source : 265f973959d031617beb11852bb51e7d5f90c8bc
Instead of having the desktop[1604]-test images currently bake in a
minidump_stackwalk binary from some random S3 URL, use the binary listed
in the in-tree tooltool manifest that we use for buildbot test jobs. As
a nice side-effect, this will ensure that the desktop-test images get
rebuilt whenever that manifest is updated with a new version, so they
will continue to use the right version in the future.
MozReview-Commit-ID: 6bThddwq6p1
--HG--
extra : rebase_source : 31111e1ae8c10a72c3635bc365babe7d5b1fb4e3
Now that we've removed support for using easy_install, we no longer
need the "install_method" argument to specify how we want to install
packages since there is only one method: pip. So remove that code.
MozReview-Commit-ID: BmjerQtfHov
--HG--
extra : rebase_source : 44427108c5a043ed929747323ea539dcda10c1cb
Support for easy_install was added in bug 761809 as part of supporting
pywin32. We just removed support for pywin32. And there are no in-tree
consumers using the "easy_install" install method. Furthermore,
easy_install is effectively deprecated as a package install mechanism:
pip should always be used.
So, we remove support for easy_install from mozharness.
MozReview-Commit-ID: CN1meLukqY6
--HG--
extra : rebase_source : 883e427f0b5b634a519c3564dd31577e9b164414
pywin32 was removed as a requirement to run Talos in bug 726700,
~3 years ago. The references in mozharness were never updated,
apparently.
MozReview-Commit-ID: FMYxLCNa63H
--HG--
extra : rebase_source : 424b9b301a1c615acd3fd221df50e10a6c00d2cb
Instead of having the desktop[1604]-test images currently bake in a
minidump_stackwalk binary from some random S3 URL, use the binary listed
in the in-tree tooltool manifest that we use for buildbot test jobs. As
a nice side-effect, this will ensure that the desktop-test images get
rebuilt whenever that manifest is updated with a new version, so they
will continue to use the right version in the future.
MozReview-Commit-ID: 6bThddwq6p1
--HG--
extra : rebase_source : eafefb980fe398dda435ad066145ffb8d7003d8f
run-task is our new universal wrapper for executing tasks. Add it
to desktop-build.
MozReview-Commit-ID: BCYHVRdUopQ
--HG--
extra : rebase_source : e2106b76c222a410920086faecad4d45833ff73c
In preparation for switching desktop-build to use run-task and
its VCS management.
MozReview-Commit-ID: 17WBMQhJxaV
--HG--
extra : rebase_source : a79709f5164687782b540c356c3888ee4e298fbc
As part of this, we had to teach install-mercurial.sh to detect
CentOS and install from RPM or source. While we can support
installing from an RPM on CentOS 6, this code is currently disabled
because the RPM we have is built against Python 2.6, which doesn't
support TLS 1.2. Since we have Python 2.7 on the image and this
Python 2.7 install supports TLS 1.2, we build Mercurial from source
using this Python 2.7 install.
We also added a "system setup" shell script. This matches the
conventions used for the desktop-test images.
MozReview-Commit-ID: 7cHN54n7aQF
--HG--
extra : rebase_source : b8ccddf0da76e94ac4064786f3b0ffa0719c9078
extra : source : cc6b486fb6bf92a408fb608283ecd8de4c4419c2
I will add more stuff to common.sh in the future in order to justify
its existence. Not in this bug though.
MozReview-Commit-ID: Lx7MJwBMH0w
--HG--
extra : rebase_source : fe6f51a9b6910abd9dedfda54c0bc8ebd3c3551e
Vendoring: more reliable, more determinism, more secure.
MozReview-Commit-ID: BYUUj4ZpndD
--HG--
extra : rebase_source : 4a1125efcca1fb50d5c191d3aadb0d11d442b628
Build tasks currently require a checkout of the build/tools repository.
I wish this weren't true and that all files references from this repo
were part of mozilla-central or tooltool, but that's how things are.
In preparation for running build tasks with run-task, teach run-task
to perform a checkout of the build/tools repo. Ideally we'd support
configuring the URL to this repository. But I'm not implementing that
since I'd prefer we stop relying on the build/tools repo.
MozReview-Commit-ID: B2Y1NwS3niO
--HG--
extra : rebase_source : bcad2f101e94411a5defd655247ed4ace250a852
Previously, we assumed we only could have a single version control
checkout: Gecko/Firefox. The code reflected this by not passing
arguments to the vcs_checkout function.
Upcoming commits will introduce the need to perform a checkout of the
build/tools repository. In preparation for this, refactor the VCS
functionality so it is generic and can work on any repo.
MozReview-Commit-ID: B0Act9fz2Ee
--HG--
extra : rebase_source : 512d0ccb15adce5ed95c4623562eb47535aef29b
os.walk() won't explicitly yield the root directory. So we need to
update it explicitly when doing a recursive chown.
MozReview-Commit-ID: JC0PNsk5gFK
--HG--
extra : rebase_source : ddfd437cd5e6bffb8780baf23813b88dd06e471d
The WebDriver specification mandates that the page loading timeout must
be five minutes, and the script timeout 30 seconds.
MozReview-Commit-ID: E82jGXCb2ch
--HG--
extra : rebase_source : e1015cbf1cb01b7b48948592be9a022b87670118
The `get` function in testing/marionette/listener.js used an evaluated
if-condition test to determine if a page timeout was given. This would
fail if passed 0 because 0 evaluates to false in JavaScript.
This patch fixes the incorrect type check by looking at whether the
variable has been defined or not.
MozReview-Commit-ID: 39vDZRjKAFb
--HG--
extra : rebase_source : f8100e05f9b1165e20b5aaab6e89b09fd110b3d2
The input type for the `ms` field when passing the old JSON schema that
puts Marionette into the backwards compatible behaviour, accepts string
types that are `parseInt`ed into an integer. This change adds a test
for this.
MozReview-Commit-ID: GJ3ibit7tyG
--HG--
extra : rebase_source : f8ddc6fa46f8917afd650eeabdaf2916c5a3bc04
Proxxy is only configured in buildbot land. Don't enable it in
TaskCluster.
Ideally, we'd only enable proxxy if we detect we're in a buildbot
environment. But the change in this commit is more conservative
and aligns with existing behavior.
MozReview-Commit-ID: HBCdQ6MkYGa
--HG--
extra : rebase_source : 08c753d7af7a4ee95c557d9deb6401c4f2da4547
So we can detect when we're running on TaskCluster. This will
be used to adjust environment settings accordingly.
MozReview-Commit-ID: JEG1E3tWsc5
--HG--
extra : rebase_source : 2acb70bd9accbde44ccb8530002ba1e892b94ce2
This leak checker may be triggering a shutdown leak on Windows,
doesn't work with e10s, and should not be needed now that ttaubert
fixed the ++DOMWINDOW leak detector to work.
The additional GCs and CCs this patch adds used to be run as part of
cc-analyzer.js, and are needed to avoid window leaks in tests.
MozReview-Commit-ID: IzZI6h2SCr2
--HG--
extra : rebase_source : 191335abb9abf48c5be0eb48db7cf8629e798918
This allows the logs to work with the structured reftest viewer.
MozReview-Commit-ID: CY71vSdDjLP
--HG--
extra : rebase_source : 6b83d98aff1c5e73ac0a802b5a83b8be95adf59a
Downloads geckodriver from tooltool when wdspec tests are being run,
and adds the --webdriver-binary argument
MozReview-Commit-ID: AJeP0YDk7Yl
--HG--
extra : rebase_source : 497f25c5af32b1851adf3a6f0b90a20640b6ccc6
Failing to find symbols in this case should be turned into a warning rather than dumping the traceback
since we're going to rely on mozcrash doing the right thing later on.
This will reduce unnecessary reporting of symbols not being available.
MozReview-Commit-ID: GXO01B7vzGV
--HG--
extra : rebase_source : 99ff82ffca6eed209ce6fd31ab747239d7100516
The virtualenv is placed in the "work dir" by default. If we
clobber the "work dir" at the beginning of the job, the parent
directory of the virtualenv may not exist and virtualenv creation
will fail because we set cwd to the work dir.
Fix that by ensuring the work dir / cwd always exists when
creating the virtualenv.
MozReview-Commit-ID: FAZPP1Sm22k
--HG--
extra : rebase_source : 126443cbcd5c83aeb47848bfc90ae28be9c9f596
When we initially implemented support for robustcheckout, we didn't
have the magic "%include" syntax in Dockerfiles. So we used tooltool
to download robustcheckout.py to the image.
Now that we have nice things, we can use the vendored robustcheckout.py
file.
As part of this, I realized we're inconsistently using /tmp, /setup
and /build for files used during image building. That should probably
be cleaned up. I'd rather not bloat scope for this bug, however.
MozReview-Commit-ID: D99Gcdw1DId
--HG--
extra : rebase_source : 3f361da3088988423b50786d990afba662d297d2
From changeset 3282813aa892f0fc247181a33ce0bde2b751da50 from the
version-control-tools repo. File added without modifications.
Upstream change was peer reviewed.
Failing to find symbols in this case should be turned into a warning rather than dumping the traceback
since we're going to rely on mozcrash doing the right thing later on.
This will reduce unnecessary reporting of symbols not being available.
MozReview-Commit-ID: GXO01B7vzGV
--HG--
extra : rebase_source : 5fa15dcf89bedea2b4e6ff52f6d06461fe5e208d
Check try message for --artifact even if fx_desktop_build.py is run with
--skip-buildbot-actions
We can't rely on buildbot config. Add checks to TryToolsMixin._extract_try_message so
that it works even if self.buildbot_config is None.
MozReview-Commit-ID: 1xErjuOArBe
--HG--
extra : rebase_source : 2f3204b37e67fd9a77dbff0fa93ab894b08181c1
These are the only 2 definitions of the hg.mozilla.org certificate
fingerprint in mozilla-central. The certificate changed on
2016-09-26. So update the fingerprints.
This /might/ be a cargo cult because automation should be pinning
the hg.mozilla.org certificate everywhere. An alternative to this
commit would be to remove the fingerprint pinning from these
scripts. But if these scripts are run by humans, we may want to keep
the pinning in.
MozReview-Commit-ID: 4FUhAGc2oqx
--HG--
extra : rebase_source : fa8889ffbb70c14270acde67121192f7c1932258
If we don't catch HTTPError, the whole job fails since we get an uncaught exception.
MozReview-Commit-ID: 8jwW7ZSieyC
--HG--
extra : rebase_source : a184fe32bb73e786bd874a1c5f298d2b2c0bca83
HSTS priming changes the order of mixed-content blocking and HSTS
upgrades, and adds a priming request to check if a mixed-content load is
accesible over HTTPS and the server supports upgrading via the
Strict-Transport-Security header.
Every call site that uses AsyncOpen2 passes through the mixed-content
blocker, and has a LoadInfo. If the mixed-content blocker marks the load as
needing HSTS priming, nsHttpChannel will build and send an HSTS priming
request on the same URI with the scheme upgraded to HTTPS. If the server
allows the upgrade, then channel performs an internal redirect to the HTTPS URI,
otherwise use the result of mixed-content blocker to allow or block the
load.
nsISiteSecurityService adds an optional boolean out parameter to
determine if the HSTS state is already cached for negative assertions.
If the host has been probed within the previous 24 hours, no HSTS
priming check will be sent.
MozReview-Commit-ID: ES1JruCtDdX
--HG--
extra : rebase_source : 2ac6c93c49f2862fc0b9e595eb0598cd1ea4bedf
Python processes with a TTY have stdout line buffered by default.
Python processes without a TTY have buffered output.
Mercurial inherits whatever Python's output buffering behavior is.
This means if we invoke Mercurial without a TTY, stdout and stderr
will be fully buffered. This means output may not be sent until
there is enough output to flush the output buffer.
A consequence of this is that timings reported for `hg` commands
invoked by run-task are inaccurate. In addition, output order is
incorrect. This is because Mercurial's progress indicators print
to stderr and flush when written. This means stderr output is
getting seen by run-task but stdout remains buffered.
This commit forces Python/Mercurial to not buffer stderr and stdout
by setting the PYTHONUNBUFFERED=1 environment variable.
MozReview-Commit-ID: 7lMdrjRMBqz
--HG--
extra : rebase_source : 198ced0053fe6071a45c9df8b044b24983c225cc
We don't need a variable to hold the result. Just use return.
The "virtualenv_path" option has a default value, so it should always
be set. Add code confirming that. And refactor the code to use
less indentation. And remove a branch that can never occur since
the virtualenv path is guaranteed to be defined.
MozReview-Commit-ID: DZ6LnlxZJFj
--HG--
extra : rebase_source : 46682e9d33beb43e0b4fc181b9163afd373e7f70
Not sure why we support this. The code goes all the way back to the
import of mozharness 0.4 into the old mozharness Mercurial repo in
bug 651974.
Having fewer variations makes it easier to search for usage. So nuke
the variation.
MozReview-Commit-ID: IgwLMdvXGB0
--HG--
extra : rebase_source : 0f9e25b2d23a670154a024eee0264b545606cc80
The Python code is now intelligent enough to add this flag on the
command line if supported. Eliminate the copy pasta and help prevent
cargo culting.
MozReview-Commit-ID: H4rbjbbgtRd
--HG--
extra : rebase_source : 2f3acf666d73260ed97ad877f365b3091186f9e2
If mozharness is running from a source checkout, it has access to a
modern virtualenv+pip/setuptools vendored as part of the source
checkout.
This commit changes the virtualenv creation code to use the vendored
virtualenv when it is available.
A side effect of this change is that a modern version of pip will
now be used by mozharness when a source checkout is available. This
has a number of consequences.
First, modern versions of pip automatically create and cache wheels
when building packages. This should make automation faster since it can
now reuse cached wheels instead of having to download and rebuild
packages all the time.
Second, modern versions of pip support pinning package hashes. This
opens the door to use having more secure package downloads and more
determinism in our test environment.
Third, modern versions of pip require connections to package servers
be secure by default. Plaintext connections are disallowed by
default. A --trusted-host option or environment variable can be used
to override this behavior.
Since upgrading pip resulted in some jobs failing due to disallowed
connections to insecure servers, code to sniff the pip version and
add --trusted-host where it is needed/supported. This retains the
existing behavior. This is insecure. But fixing that is for another
bug.
As part of testing this, we were getting IOError inside virtualenv.py
when installing distutils:
IOError: [Errno 13] Permission denied: '/builds/slave/test/build/venv/lib/python2.7/distutils/__init__.py'
We worked around this by adding --always-copy to the virtualenv.py
invocation.
MozReview-Commit-ID: D29ao9ZASei
--HG--
extra : rebase_source : 031b2561a64ab1f89d25a3bfb8cf486a58b9f308
Now that we can detect when we're running from a source checkout,
we can start using things from source checkouts instead of relying
on host machine state or grabbing files from another server.
We start by using the vendored tooltool.py if available. This
avoids non-determinism. It avoids a possible 3rd party hosting
dependency on github.com. It avoids a possible MitM attack vector.
Wins all around.
MozReview-Commit-ID: L6hLveHZxBR
--HG--
extra : rebase_source : 67cc9d53fc0b3f92710ce41cc9f6556aa3ebbf99
We're going to start executing more mozharness scripts from a source
checkout. Rather than add config options to specify the location of
a source checkout - something that must be added to every mozharness
invocation - we teach BaseScript.__init__ to recognize when we're
running from a source checkout and set self.topsrcdir accordingly.
This will allow any script or class to check for self.topsrcdir
and change behavior accordingly.
MozReview-Commit-ID: 3uxOjol7ntR
--HG--
extra : rebase_source : 40795fe231a908b42a13581db3ee079c13138412
Without this, process output is buffered by default. This means
timestamps that mozharness prefixes to process output aren't
accurate unless the process is spewing enough output to flush the
output buffer.
Output buffering could lead to bad things. For example, a process
could emit output that would cause mozharness's output monitor to
abort the process. However, if that output is caught in limbo in
the output buffer, mozharness may take several seconds or even
minutes to react.
With this change, the mozharness process receives process output
as soon as that process writes to its standard file descriptors.
Once a newline is seen, mozharness will process it immediately.
Note that this only impacts the case where there is no output
timeout, as the existing code for output timeout uses mozprocess
and I'm pretty sure mozharness doesn't buffer output.
MozReview-Commit-ID: HBkYnfEw7Hb
--HG--
extra : rebase_source : e17b44d88f27c16b054a64c3cc2b3415297daf3b
Move packaging for Marionette from make to test_archiver by using root manifest files.
MozReview-Commit-ID: 1cxEBYQeJ2Z
**
--HG--
extra : rebase_source : 372a407d9207bfbccbfb88c689df60b8cc1abcaf
There were two assumptions preventing this output from being logged, both
related to the case a test passes and xpcshell returns 0. The first was
that we would not find crash dumps in this case, and would therefore not
need to log the full output of the test process (in the case xpcshell
returned non-zero or a test failed, we would log this output prior to checking
for crashes). The second was that if a test was eligible to retry, we wouldn't
need to store a test's output at all, because this output would only relate to
a failure that we would consider non-fatal.
The first assumption does not hold because it's possible to fatally assert
at shutdown in tests spawning child processes without causing a test failure
or non-zero exit code.
The second assumption followed from the first, and is violated when the first
is violated, because in this case we would consider a found crash fatal even
when a test was eligible to retry.
This patch reverses these assumptions and logs the full output of a test that
passes but produces crash dumps. It's not clear that the existing code intended
for a crash to ever be considered fatal when a test was eligible to retry, but
to change this criteria now would reduce our effective test coverage by
ignoring crashes that are now considered fatal, so after this patch we continue
to consider this scenario fatal. If it is determined these crashes are related
to these tests running in parallel with other tests, or they are not relevant
for some other reason, these tests should be run sequentially, or this criteria
should be changed.
MozReview-Commit-ID: 2PaFSGx2MVR
--HG--
extra : rebase_source : 34c0d1f13f4256928906729b1f3667bc395b2c56
We can assume that if middle button's click event on a link isn't consumed by any event handlers including system event group's, it will cause open new tab. With this assumption, we can avoid using setTimeout which causes random orange.
However, unfortunately, in e10s mode, the default is NOT consumed at window in bubbling phase but consumed at that time. So, when not working the link is expected, we cannot check Event.defaultPrevented. But fortunately, we can check if the page is loaded after that.
Note that for testing this, the test needs to check if an event handler which is either in default group or system group consumed a click event. However, this runs as mochitest-plain. Therefore, Event.defaultPrevented returns false if the event is consumed only in the system group's event listener. For avoiding this issue, this patch adds defaultPreventedInAnyGroups() into SpecialPowers. In SpecialPowers, Event.defaultPrevented is accessed from chrome context. Therefore, we can get the result what this test needs.
MozReview-Commit-ID: Cfn4lFR1dfI
--HG--
extra : rebase_source : 51feb768bd38f62cc19c2f4aecaaea0135190599
This also adds E402 (no imports at top of file) to the global ignore list. The
other error codes added were previously ignored by default, but now that we
have started a custom ignore list, need to be listed explicitly.
MozReview-Commit-ID: RtMuVEX6i5
--HG--
extra : rebase_source : 939bc9354f5891c680513d7e9068d0438e169132
The only difference in these files was the order that pulseaudio is
started and whether compiz is started. We rename test-ubuntu1604.sh
to test-ubuntu.sh, add some distro release detection, and add
some conditional branches so it works on both Ubuntu 12.04 and 16.04.
MozReview-Commit-ID: CaSfuDxss3d
--HG--
rename : taskcluster/scripts/tester/test-ubuntu1604.sh => taskcluster/scripts/tester/test-ubuntu.sh
extra : rebase_source : 2153d24fbf8208851a6df8728b8a820166278751
install-mercurial.sh was switching directories to /usr/local/mercurial
resulting in following actions adding files to that path. We don't
want that. So avoid the `cd` in install-mercurial.sh.
The main side effect of this change is that the desktop-test image is
now ~1.2 GB smaller because files aren't being saved to
/usr/local/mercurial.
MozReview-Commit-ID: Kyv8oXtvsda
--HG--
extra : rebase_source : f73dc49bf0fe457aebc6c858cd3fcaf6ce59ce6d
The only difference in these files was the order that pulseaudio is
started and whether compiz is started. We rename test-ubuntu1604.sh
to test-ubuntu.sh, add some distro release detection, and add
some conditional branches so it works on both Ubuntu 12.04 and 16.04.
MozReview-Commit-ID: CaSfuDxss3d
--HG--
rename : taskcluster/scripts/tester/test-ubuntu1604.sh => taskcluster/scripts/tester/test-ubuntu.sh
extra : rebase_source : 29040c1cf7baedda0aaeff4bd788d5d400c127f1
extra : source : f227ea4d52fed84e3e682de0aa4cb8869539d645
We can't add it to the base image because rebuilding the base image
breaks Valgrind due to non-deterministic package version installation
(read the bug for the ugly backstory).
MozReview-Commit-ID: ARKJZfNCRFc
--HG--
extra : rebase_source : 6a36b1289d121367c89c986f86faf1e34a38a906
extra : source : 66c7af8b26544e79b39b7180cb7338bbc2642064
Unfortunately, MapVirtualKeyEx() doesn't compute ABNT C1's scan code from its virtual keycode, 0xC1. Therefore, NativeKeyCodes.js should specify 0x0056 explicitly. Fortunately, this key in physical keyboard always generates the scan code value with any keyboard layouts. Therefore, this can test new regressions as expected.
FYI: ABNT C1 key is a key in Brazilian keyboard. It's at between "ShiftLeft" and "KeyZ".
MozReview-Commit-ID: GmpnFKOsnKD
--HG--
extra : rebase_source : 197b249740056e5c4b7c6f3b556f91f50a838d52
On Windows, some keys are called "extended key". Their scan code include 0xE000. For example, Enter key in standard position is 0x001C but Numpad's Enter key is 0xE01C. Unfortunately, both of them cause same virtual keycode value, VK_RETURN. Therefore, currently, nsIDOMWindowUtils.sendNativeKey() can synthesize only one native key event of them (only non-extended key's event). Additionally, MapVirtualKeyEx() API with MAPVK_VK_TO_VSC (even with MAPVK_VK_TO_VSC_EX) don't return extended scancode value as expected.
For solving these issues, we should include scan code value to the virtual keycode value at calling sendNativeKey().
Fortunately, virtual keycode value on Windows is 0 ~ 255 (0x00 ~ 0xFF) but aNativeKeyCode of sendNativeKey() is int32_t. So, we can use upper 16 bit for specifying scan code.
This patch explicitly specifies scan code value at defining WIN_VK_* in NativeKeyCodes.js. Additionally, this patch duplicates native virtual keycode definition for Home, End, Insert, Delete, PageUp, PageDown, ArrowUp, ArrowLeft, ArrowDown, ArrowRight and Enter as WIN_VK_* and WIN_VK_NUMPAD_*. This makes automated tests can specify both positions' keys explicitly.
Finally, this patch adds some tests to test_keycodes.xul for testing KeyboardEvent.code value of those keys in both positions.
MozReview-Commit-ID: 8n1rQ71dilg
--HG--
extra : rebase_source : 8215e56ba1ed9fc54c04eb7ca037b12c3ced5c1b
These builds can be run on taskcluster to obtain per-test (JSDebugger) code coverage with the linux64-jsdcov build and overall (GCOV) code coverage with the linux64-ccov build. The linux64-jsdcov build also needed to have leak checking disabled for debug mode.
MozReview-Commit-ID: ASgrU2X7RQV
--HG--
extra : rebase_source : b2098e4d01039edd6cff37f3e6a26c2ed3d3d3ba
These builds can be run on taskcluster to obtain per-test (JSDebugger) code coverage with the linux64-jsdcov build and overall (GCOV) code coverage with the linux64-ccov build. The linux64-jsdcov build also needed to have leak checking disabled for debug mode.
MozReview-Commit-ID: ASgrU2X7RQV
--HG--
extra : rebase_source : af40a6e582665ffcb575092586731f595a362ae4
download_unpack() is managing to download files correctly, however, sometimes we get an exception
that the zip file is corrupted.
This change adds more logging and saves the fetched file to disk in order to get uploaded as an artifact
for inspection.
MozReview-Commit-ID: 2KCK6qGNor4
--HG--
extra : rebase_source : 05f29616c90f36991582d285c6fa00d62fe06b40
In automation, we try to use pypi.pvt.build.mozilla.org nearly
everywhere. This hostname doesn't resolve in TaskCluster and
outside of buildbot automation.
A consequence of work in bug 1304176 and using a modern pip is
that we attempt to connect to all defined pip links. This was resulting
in pip attempting connections to pypi.pvt.build.mozilla.org. And
since pip was attempting retries, this resulted in a several
second delay for all pip operations if that host didn't resolve.
This commit adds a DNS lookup in mozharness before using a pip
--link. We spend a little bit of overhead in mozharness doing a
DNS lookup. In return, we guarantee we'll avoid a multiple second
pause if any links don't resolve. This is somewhat hacky.
But it seems like the easiest solution.
MozReview-Commit-ID: EecqBQSW75R
--HG--
extra : rebase_source : 9664a3694232e4ce2dec216b036ba29783c2842d
Previously, when recursively changing ownership on directories we would
only change the owner. We saw some permission denied failures in
automation where the new owner couldn't modify files or directories.
This *might* be due to the owner write bits not always being set. Or
it could be something else (such as a filesystem bug - *cough* AUFS
*cough*).
This commit changes our recursive chown implementation to ensure owner
read, write, and execute bits are set on directories.
Because we're now always calling stat(), the code for calling chown()
is made conditional because we have the stat information and can avoid
the extra system call if it would be a no-op.
MozReview-Commit-ID: JT9q3QR4Sit
--HG--
extra : rebase_source : 86ceecb3a9381390670d47d46862dad4fc38c403
Unfortunately, MapVirtualKeyEx() doesn't compute ABNT C1's scan code from its virtual keycode, 0xC1. Therefore, NativeKeyCodes.js should specify 0x0056 explicitly. Fortunately, this key in physical keyboard always generates the scan code value with any keyboard layouts. Therefore, this can test new regressions as expected.
FYI: ABNT C1 key is a key in Brazilian keyboard. It's at between "ShiftLeft" and "KeyZ".
MozReview-Commit-ID: GmpnFKOsnKD
--HG--
extra : rebase_source : 37f78552a1ebba6f61c38add0138b84ddef36c3e
On Windows, some keys are called "extended key". Their scan code include 0xE000. For example, Enter key in standard position is 0x001C but Numpad's Enter key is 0xE01C. Unfortunately, both of them cause same virtual keycode value, VK_RETURN. Therefore, currently, nsIDOMWindowUtils.sendNativeKey() can synthesize only one native key event of them (only non-extended key's event). Additionally, MapVirtualKeyEx() API with MAPVK_VK_TO_VSC (even with MAPVK_VK_TO_VSC_EX) don't return extended scancode value as expected.
For solving these issues, we should include scan code value to the virtual keycode value at calling sendNativeKey().
Fortunately, virtual keycode value on Windows is 0 ~ 255 (0x00 ~ 0xFF) but aNativeKeyCode of sendNativeKey() is int32_t. So, we can use upper 16 bit for specifying scan code.
This patch explicitly specifies scan code value at defining WIN_VK_* in NativeKeyCodes.js. Additionally, this patch duplicates native virtual keycode definition for Home, End, Insert, Delete, PageUp, PageDown, ArrowUp, ArrowLeft, ArrowDown, ArrowRight and Enter as WIN_VK_* and WIN_VK_NUMPAD_*. This makes automated tests can specify both positions' keys explicitly.
Finally, this patch adds some tests to test_keycodes.xul for testing KeyboardEvent.code value of those keys in both positions.
MozReview-Commit-ID: 8n1rQ71dilg
--HG--
extra : rebase_source : 0f4bb9193aa06cd7985590636b77a6e2a71ac2e4
This commit does a few things. First, it introduces a property on the
"test_description" schema that, if defined, will cause run-task to
perform a gecko checkout. The presence of the property also configures
the needed scopes and caches.
Second, we introduce the property on web platform test tasks so a
Gecko checkout is present. We also add volumes for the Mercurial
paths to the Docker images. We strictly only need this for
desktop1604-test since WPT tests don't run on desktop-test. However,
desktop-test and desktop1604-test are nearly mirror images of each
other and I feel it is best to keep them in sync.
This commit will make WPT tasks slower on average because they will
need to create a checkout. To add salt to the wound, the checkout
isn't used. However, we need to prove that performing checkouts in
test tasks in automation works at scale. I'd prefer to have this running
for a few weeks and incurring a wall time execution penalty than to
have a giant series of commits backed out because source checkouts
aren't working.
MozReview-Commit-ID: 9UrSWSSmr3w
--HG--
extra : rebase_source : 7b3786f5c612d47dc3b0e165b4abe0c47e8af9ed
This updates the manifest without loading any of the test-running
infrastructure, or requiring a build.
MozReview-Commit-ID: HJko5gUB3ov
--HG--
extra : rebase_source : 8ce14b2e76a6f1daf286ff6758c57604c072a6ad
We believe we're getting incomplete bytes when fetching files from S3 to our EC2 instances.
This patch should help give us more information and retry few times before failing.
MozReview-Commit-ID: 7tUzZmS8Zph
--HG--
extra : rebase_source : f8c052c92d3ccccf18daf6cbf9832d8ec48a6ecd
The content of this bug (1216843) has changed since it filed initially,
so we should change bug numbers in our source tree.
Re-generating ini file re-ordered items in the ini file.
MozReview-Commit-ID: HnJGJDSmZl3