Our current deprecation warning mechanism relies on ui object. They are case
where we cannot have access to the UI object. On a general basis we avoid using
the python mechanism for deprecation warning because up to Python 2.6 it is
exposing warning to unsuspecting user who cannot do anything to deal with them.
So we build a "safe" strategy to hide this warnings behind a flag in an
environment variable. The test runner set this flag so that tests show these
warning. This will help us marker API as deprecated for extensions to update
their code.
Duplicating entire tests just because the output is different is both error
prone and can make the tests harder to read. This harnesses the existing '(?)'
infrastructure, both to improve readability, and because it seemed like the path
of least resistance.
The form is:
$ test_cmd
output (hghave-feature !) # required if hghave.has_feature(), else optional
out2 (no-hghave-feature2 !) # req if not hghave.has_feature2(), else optional
I originally extended the '(?)' syntax. For example, this:
2 r4/.hg/cache/checkisexec (execbit ?)
pretty naturally reads as "checkisexec, if execbit". In some ways though, this
inverts the meaning of '?'. For '(?)', the line is purely optional. In the
example, it is mandatory iff execbit. Otherwise, it is carried forward as
optional, to preserve the test output. I tried it the other way, (listing
'no-exec' in the example), but that is too confusing to read. Kostia suggested
using '!', and that seems fine.
Previously, if a series of optional output lines marked with '(?)' had a (glob)
in one of the first lines, the output would be reordered such that it came last
if none of the lines were output. The (re) declaration wasn't affected, which
was helpful in figuring this out. There were no tests for '(re) (?)' so add
that to make sure everything plays nice.
Hooks related to the transaction are aware of the transaction id. By definition
this txn-id is unique and different for each transaction. As a result it can
never be predicted in test and always needs matching. As a result, touching any
like with this data is annoying. We solve the problem once and for all by
installing an automatic replacement. In test, this will now show as:
TXNID=TXN:$ID$
This is similar to what 9704c8e70d2d does. Since 1363aaf74791 has changed
"127.0.0.1" to "$LOCALIP". The glob pattern needs update accordingly. It is
expected to fix tests running in some BSD jails.
Plenty of tests break when "make tests" is run while environment
variables "HGPLAIN" or "HGPLAINEXCEPT" are set (test "test-obsolete-
checkheads.t" is just a single example).
This patch causes script "run-tests.py" to also remove these two
variables from the environment the tests are executed in.
Previously, we only set web.ipv6 if IPv6 is used, but not on the IPv4 case.
Since we already have set web.address, it makes sense to move "web.ipv6" out
from "extra config options".
Previously, "hg serve" will listen on "", which is not clear which interface
it will actually listen on - it could listen on all interfaces (ex. 0.0.0.0
on IPv4).
The run-tests.py script only checks "localhost" for available ports. So
let's make it the same for "hg serve" by explicitly setting "web.address" to
"localhost".
This resolves some IPv6 EADDRINUSE errors.
This patch replaces hardcoded 127.0.0.1 with $LOCALIP in all tests.
Till now, the IPv6 series should make tests pass on common IPv6 systems
where the local device has the address "::1" and the hostname "localhost"
resolves to "::1".
Previously, tests hard-code local IP address as "127.0.0.1". That won't work
for IPv6.
This patch exports the $LOCALIP environment variable, which is set to "::1"
if we decide to use IPv6.
Previously, run-tests.py only exports HGPORT, and scripts in tests do not
know if IPv6 should be used. And that breaks scripts like dumbhttp.py which
always uses IPv4.
This patch makes run-tests.py export HGIPV6, which can help test scripts
like dumbhttp.py and tinyproxy.py to decide whether to use IPv6 or not.
To make IPv6 work, there are multiple areas that need to fix. Before they
all get fixed, use IPv4 by default.
This should fix tests caused on IPv6 systems.
As explained by the previous patch, we need to set "web.ipv6=True" if we
decide to use IPv6. Otherwise "hg serve" will still try to listen on IPv4.
This patch makes it so by appending web.ipv6 to "extra configs".
This patch was tested in a Linux system with IPv6, by the following steps:
1. Change hgweb/server.py temporarily to write a file if
IPv6HTTPServer.__init__ is called.
2. run-tests.py -l --keep-tmpdir test-serve.t
3. Check the generated .hgrc, make sure it sets web.ipv6=1.
4. Check the log file to make sure IPv6HTTPServer.__init__ is called.
As explained by the previous patch, checkportisavailable() should only check
the preferred family - either IPv4 or IPv6, not both.
This patch makes it so.
Previously, checkportisavailable returns True if the port is free either on
IPv4 or IPv6, but the hg server only uses IPv4 by default. That leads to
issues when IPv4 port is not free but the IPv6 one is.
To address that, run-tests should stick with either IPv4 or IPv6. This patch
adds a function similar to checkportisavailable to test if IPv6 is
available, and assigns the result to a variable.
The new function was tested in a Linux system script with the following
steps:
1. Run "ip addr del ::1/128 dev lo" to delete lo's IPv6 address,
Confirm checkipv6available() returns False.
2. Run "ip addr add ::1/128 dev lo" to add back lo's IPv6 address.
Confirm checkipv6available() returns True.
3. Start a web server taking the 8000 port.
Confirm checkipv6available(8000) is still True.
This is a follow-up of "runtests: check ports on IPv6 address". On some
platforms, "socket.AF_INET6" exists while that does not necessarily mean the
platform support IPv6 - when initializing a socket using "socket.socket", it
could fail with EPROTONOSUPPORT. So treat that as "Port unavailable".
Previously, checkportisavailable only checks ports on the IPv4 address. This
patch makes it check IPv6 as well. It'll be useful if "localhost" does not
have an IPv4 address, or its IPv4 address does not exist somehow.
We do this so that any linters installed via pip install --user don't
break. See https://docs.python.org/2/library/site.html#site.USER_BASE
for a description of what this nonsense is all about.
An alternative would be to not set HOME, but that'll cause other
problems (see issue2707), or to forward every single path entry from
sys.path in PYTHONPATH (which seems sketchy in its own way).
Some systems don't have a 127/8 address for localhost (I noticed this
on a FreeBSD jail). In order to work around this, use 127.0.0.1 as a
glob pattern. A future commit will update needed output lines and add
a requirement to check-code.py.
This patch includes addition of absolute_import and print_function to the
files where they are missing. The modern importing conventions are also followed.
In py2, json.dumps includes a trailing space after a comma at the
end of lines. The py3 behavior which omits the trailing space is
preferable, so we're going to strip it.
Without this, my python 2.6 virtualenv test run with --pure and
--local fails with:
+ ImportError: Python minor version mismatch: The Mercurial extension modules were compiled with Python 2.7.8, but Mercurial is currently using Python with sys.hexversion=33950192: Python 2.6.9 (unknown, Apr 13 2016, 12:40:12)
+ [GCC 4.9.2 20141101 (Red Hat 4.9.2-1)]
+ at: ~/hg/py26/bin/python
Several tests fail with chg for several reasons such as loaded chgserver
extension, running uisetup() per server instead of per runcommand, etc.
Since these tests can't/shouldn't be changed to be chg friendly, we need
a flag to skip them.
This patch explicitly drops CHGHG environment if chg isn't involved. This
way, hghave can just check if CHGHG exists.
Without this, sometimes installerrs generated errors
about no such file. It also did not work well when you
had multiple tests runners running around.
It also did not make sense to pollute the repository test
directory with the log file.
The regular expression in use passed tests because the test repo only
has single-digit changesets present. When I tried to use this for real
today, it broke, because the regular expression would only match a
single digit.
https://xkcd.com/1171/, or something like that.
72b40f92c680 enabled lines that were not matched to be found later in cases of jitter.
Unfortunately, in this model an optional line would always jitter to the end when
it is not present. That is not ideal.
It would be possible to do better, by queuing all writes until the end in case
an optional line jitters, but for now, it is simpler to assume optional lines
have a fixed place in the stream.
Before this patch, if --chg or --with-chg is specified, all tests are using
the same chgserver socket. Since the chg client holds a lock when it starts a
new server, and every test needs at least a new chg server due to different
HGRCPATH affecting the confighash, the result is a lot of tests will be
timed out if -j is large (for example, 50 or 100).
This patch solves the issue by using different chg socket directories for
different tests.
Currently, very few parts of Mercurial run under Python 3, notably the
test harness.
We want to write tests that run Python 3. For example, we want to
extend test-check-py3-compat.t to parse and load Python files.
However, we have a problem: finding appropriate files requires
running `hg files` and this requires Python 2 until `hg` works
with Python 3.
As a temporary workaround, we add --with-python3 to the test harness
to allow us to define the path to a Python 3 interpreter. This
interpreter is made available to the test environment via $PYTHON3 so
tests can run things with Python 3 while the test harness and `hg`
invocations continue to run from Python 2. To round out the feature,
a "py3exe" hghave check has been added.
Instead of treating expected output as happening in a precise order,
and assuming that if a line is missing it will never happen,
assume that expected output is a prioritized list of likely matching
lines.
This means that if:
foo/bar (glob)
baz/bad (glob)
changes to:
baz/bad
foo/bar
instead of generating:
baz/bad
foo/bar
For which we've lost both (glob) markers,
we will match both lines and generate:
baz/bad (glob)
foo/bar (glob)
This retains any special annotations we have for lines.
Current pidfile logic will only keep the pid of the newest server, which is
not very useful if we want to kill all servers, and will become outdated if
the server auto exits after being idle for too long.
Besides, the server-side pidfile writing logic runs before chgserver gets
confighash so it's not trivial to append confighash to pidfile basename like
we did for socket file.
This patch removes --pidfile from the command starting chgserver and switches
to an alternative way (unlink socket file) to stop the server.
Previously, after matching a single line, any contiguous subsequent lines ending
with (?) would be added to the output and removed from the expected output.
This is a problem if the subsequent test output would have matched the consumed
(?) line, because it kept the optional line and then added a duplicate without
the (?) [1]. Instead, wait until there is nothing more to match before handling
the leftovers.
[1] https://www.mercurial-scm.org/pipermail/mercurial-devel/2016-February/080197.html
At one point run-tests.py and test-run-tests.t worked and passed
under Python 3.5. Various changes to run-tests.py over the past
several months appear to have broken Python 3.5 compatibility.
This patch implements various fixes (all related to str/bytes type
coercion) to make run-tests.py and test-run-tests.t mostly work
again. There are still a few failures in test-run-tests.t due to
issues importing mercurial.* modules. But at least run-tests.py
seems to work under 3.5 again.
When reloading tests, run-tests.py was assuming that it could look
up the test by the basename, which only works if you are running
tests which are in the current directory.
This patch changes that lookup to use the full path. This is all
that was needed, and does not appear to cause any problems for
any of the existing testing work flows based on running the
suggested commands at the top of run-tests.py.
Motivation: In order to test Mercurial with Hypothesis (according
to https://www.mercurial-scm.org/wiki/HypothesisPlan) it is
useful to be able to generate temporary test files and execute
them. Generating temporary files in the tests/ directory leads to
a lot of suboptimal clutter.
