path: root/t/
AgeCommit message (Collapse)Author
2019-11-23tests: add 'test_bool_env' to catch non-bool GIT_TEST_* valuesSZEDER Gábor
Since 3b072c577b (tests: replace test_tristate with "git env--helper", 2019-06-21) we get the normalized bool values of various GIT_TEST_* environment variables via 'git env--helper'. Now, while the 'git env--helper' command itself does catch invalid values in the environment variable or in the given --default and exits with error (exit code 128 or 129, respectively), it's invoked in conditions like 'if ! git env--helper ...', which means that all invalid bool values are interpreted the same as the ordinary 'false' (exit code 1). This has led to inadvertently skipped httpd tests in our CI builds for a couple of weeks, see 3960290675 (ci: restore running httpd tests, 2019-09-06). Let's be more careful about what the test suite accepts as bool values in GIT_TEST_* environment variables, and error out loud and clear on invalid values instead of simply skipping tests. Add the 'test_bool_env' helper function to encapsulate the invocation of 'git env--helper' and the verification of its exit code, and replace all invocations of that command in our test framework and test suite with a call to this new helper (except in '', of course). $ GIT_TEST_GIT_DAEMON=YesPlease ./ fatal: bad numeric config value 'YesPlease' for 'GIT_TEST_GIT_DAEMON': invalid unit error: test_bool_env requires bool values both for $GIT_TEST_GIT_DAEMON and for the default fallback Signed-off-by: SZEDER Gábor <> Signed-off-by: Junio C Hamano <>
2019-06-21tests: replace test_tristate with "git env--helper"Ævar Arnfjörð Bjarmason
The test_tristate helper introduced in 83d842dc8c ("tests: turn on network daemon tests by default", 2014-02-10) can now be better implemented with "git env--helper" to give the variables in question the standard boolean behavior. The reason for the "tristate" was to have all of false/true/auto, where "auto" meant either "false" or "true" depending on what the fallback was. With the --default option to "git env--helper" we can simply have e.g. GIT_TEST_HTTPD where we know if it's true because the user asked explicitly ("true"), or true implicitly ("auto"). This breaks backwards compatibility for explicitly setting "auto" for these variables, but I don't think anyone cares. That was always intended to be internal. This means the test_normalize_bool() code in goes away in addition to test_tristate(). We still need the test_skip_or_die() helper, but now it takes the variable name instead of the value, and uses "git env--bool" to distinguish a default "true" from an explicit "true" (in those "explicit true" cases we want to fail the test in question). Signed-off-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Junio C Hamano <>
2019-03-14git-daemon: use 'test_atexit` to stop 'git-daemon'Johannes Schindelin
Use 'test_atexit' to run cleanup commands to stop 'git-daemon' at the end of the test script or upon interrupt or failure, as it is shorter, simpler, and more robust than registering such cleanup commands in the trap on EXIT in the test scripts. Note that in '' the daemon is stopped and then re-started in the middle of the test script; take care that the cleanup functions to stop the daemon are only registered once. Signed-off-by: Johannes Schindelin <> Signed-off-by: SZEDER Gábor <> Signed-off-by: Junio C Hamano <>
2019-03-14t/lib-git-daemon: make sure to kill the 'git-daemon' processSZEDER Gábor
After 'start_git_daemon' starts 'git daemon' (note the space in the middle) in the background, it saves the background process' PID, so the daemon can be stopped at the end of the test script. However, 'git-daemon' is not a builtin but a dashed external command, which means that the dashless 'git daemon' executes the dashed 'git-daemon' command, and, consequently, the PID recorded is not the PID of the "real" daemon process, but that of the main 'git' wrapper. Now, if a test script involving 'git daemon' is interrupted by ctrl-C, then only the main 'git' process is stopped, but the real daemon process tends to survive somehow, and keeps on running in the background indefinitely, keeping the daemon's port to itself, and thus preventing subsequent runs of the same test script. Work this around by running 'git daemon' with the '--pidfile=...' option to save the PID of the real daemon process, and kill that process in 'stop_git_daemon' as well. Signed-off-by: SZEDER Gábor <> Signed-off-by: Junio C Hamano <>
2019-01-18Merge branch 'sg/stress-test'Junio C Hamano
Flaky tests can now be repeatedly run under load with the "--stress" option. * sg/stress-test: test-lib: add the '--stress' option to run a test repeatedly under load test-lib-functions: introduce the 'test_set_port' helper function test-lib: set $TRASH_DIRECTORY earlier test-lib: consolidate naming of test-results paths test-lib: parse command line options earlier test-lib: parse options in a for loop to keep $@ intact test-lib: extract Bash version check for '-x' tracing test-lib: translate SIGTERM and SIGHUP to an exit
2019-01-07test-lib-functions: introduce the 'test_set_port' helper functionSZEDER Gábor
Several test scripts run daemons like 'git-daemon' or Apache, and communicate with them through TCP sockets. To have unique ports where these daemons are accessible, the ports are usually the number of the corresponding test scripts, unless the user overrides them via environment variables, and thus all those tests and test libs contain more or less the same bit of one-liner boilerplate code to find out the port. The last patch in this series will make this a bit more complicated. Factor out finding the port for a daemon into the common helper function 'test_set_port' to avoid repeating ourselves. Take special care of test scripts with "low" numbers: - Test numbers below 1024 would result in a port that's only usable as root, so set their port to '10000 + test-nr' to make sure it doesn't interfere with other tests in the test suite. This makes the hardcoded port number in '' unnecessary, remove it. - The shell's arithmetic evaluation interprets numbers with leading zeros as octal values, which means that test number below 1000 and containing the digits 8 or 9 will trigger an error. Remove all leading zeros from the test numbers to prevent this. Note that the 'git p4' tests are unlike the other tests involving daemons in that: - '' doesn't use the test's number for unique port as is, but does a bit of additional arithmetic on top [1]. - The port is not overridable via an environment variable. With this patch even 'git p4' tests will use the test's number as default port, and it will be overridable via the P4DPORT environment variable. [1] Commit fc00233071 (git-p4 tests: refactor and cleanup, 2011-08-22) introduced that "unusual" unique port computation without explaining why it was necessary (as opposed to simply using the test number as is). It seems to be just unnecessary complication, and in any case that commit came way before the "test nr as unique port" got "standardized" for other daemons in commits c44132fcf3 (tests: auto-set git-daemon port, 2014-02-10), 3bb486e439 (tests: auto-set LIB_HTTPD_PORT from test name, 2014-02-10), and bf9d7df950 (t/ improve svnserve tests with parallel make test, 2017-12-01). Signed-off-by: SZEDER Gábor <> Signed-off-by: Junio C Hamano <>
2019-01-07Revert "t/lib-git-daemon: record daemon log"Thomas Gummerer
This reverts commit 314a73d658 (t/lib-git-daemon: record daemon log, 2018-01-25), which let tests use the output of git-daemon. The previous commit removed the last user of deamon.log in the tests, there's no good way to make checking for output in the log race-proof. Revert this commit as well, to make sure others are not tempted to use daemon.log in tests in the future, which would lead to racy tests. The original commit had one change that still makes sense, namely switching read/echo for "read -r" and "printf", which relays the data more faithfully. Don't revert that piece here, as it is still a useful change. Suggested-by: Jeff King <> Signed-off-by: Thomas Gummerer <> Signed-off-by: Junio C Hamano <>
2018-11-27t/lib-git-daemon: fix signal checkingSZEDER Gábor
Test scripts checking 'git daemon' stop the daemon with a TERM signal, and the 'stop_git_daemon' helper checks the daemon's exit status to make sure that it indeed died because of that signal. This check is bogus since 03c39b3458 (t/lib-git-daemon: use test_match_signal, 2016-06-24), for two reasons: - Right after killing 'git daemon', 'stop_git_daemon' saves its exit status in a variable, but since 03c39b3458 the condition checking the exit status looks at '$?', which at this point is not the exit status of 'git daemon', but that of the variable assignment, i.e. it's always 0. - The unexpected exit status should abort the whole test script with 'error', but it doesn't, because 03c39b3458 forgot to negate 'test_match_signal's exit status in the condition. This patch fixes both issues. Signed-off-by: SZEDER Gábor <> Signed-off-by: Junio C Hamano <>
2018-01-25t/lib-git-daemon: add network-protocol helpersJeff King
All of our git-protocol tests rely on invoking the client and having it make a request of a server. That gives a nice real-world test of how the two behave together, but it doesn't leave any room for testing how a server might react to _other_ clients. Let's add a few test helper functions which can be used to manually conduct a git-protocol conversation with a remote git-daemon: 1. To connect to a remote git-daemon, we need something like "netcat". But not everybody will have netcat. And even if they do, the behavior with respect to half-duplex shutdowns is not portable (openbsd netcat has "-N", with others you must rely on "-q 1", which is racy). Here we provide a "fake_nc" that is capable of doing a client-side netcat, with sane half-duplex semantics. It relies on perl's IO::Socket::INET. That's been in the base distribution since 5.6.0, so it's probably available everywhere. But just to be on the safe side, we'll add a prereq. 2. To help tests speak and read pktline, this patch adds packetize() and depacketize() functions. I've put fake_nc() into, since that's really the only server where we'd need to use a network socket. Whereas the pktline helpers may be of more general use, so I've added them to Programs like upload-pack speak pktline, but can talk directly over stdio without a network socket. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2018-01-25t/lib-git-daemon: record daemon logJeff King
When we start git-daemon for our tests, we send its stderr log stream to a named pipe. We synchronously read the first line to make sure that the daemon started, and then dump the rest to descriptor 4. This is handy for debugging test output with "--verbose", but the tests themselves can't access the log data. Let's dump the log into a file, as well, so that future tests can check the log. There are a few subtleties worth calling out here: - we'll continue to send output to descriptor 4 for viewing/debugging, which would imply swapping out "cat" for "tee". But we want to ensure that there's no buffering, and "tee" doesn't have a standard way to ask for that. So we'll use a shell loop around "read" and "printf" instead. That ensures that after a request has been served, the matching log entries will have made it to the file. - the existing first-line shell loop used read/echo. We'll switch to consistently using "read -r" and "printf" to relay data as faithfully as possible. - we open the logfile for append, rather than just output. That makes it OK for tests to truncate the logfile without restarting the daemon (the OS will atomically seek to the end of the file when outputting each line). That allows tests to look at the log without worrying about pollution from earlier tests. Helped-by: Lucas Werkmeister <> Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2017-03-10t/interop: add test of old clients against modern git-daemonJeff King
This test just checks that old clients can clone and fetch from a newer git-daemon. The opposite should also be true, but it's hard to test ancient versions of git-daemon because they lack basic options like "--listen". Note that we have to make a slight tweak to the lib-git-daemon helper from the regular tests, so that it starts the daemon with our correct git.a version. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2016-07-06t/lib-git-daemon: use test_match_signalJeff King
When git-daemon exits, we expect it to be with the SIGTERM we just sent it. If we see anything else, we'll complain. But our check against exit code "143" is not portable. For example: $ ksh93 [...] error: git daemon exited with status: 271 We can fix this by using test_match_signal. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2016-01-28tests: turn off git-daemon tests if FIFOs are not availableJohannes Schindelin
The Git daemon tests create a FIFO first thing and will hang if said FIFO is not available. This is a problem with Git for Windows, where `mkfifo` is an MSYS2 program that leverages MSYS2's POSIX emulation layer, but `git-daemon.exe` is a MINGW program that has not the first clue about that POSIX emulation layer and therefore blinks twice when it sees MSYS2's emulated FIFOs and then just stares into space. This lets and pass. Signed-off-by: Stepan Kasal <> Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2014-03-05Merge branch 'jk/run-network-tests-by-default'Junio C Hamano
Teach "make test" to run networking tests when possible by default. * jk/run-network-tests-by-default: tests: turn on network daemon tests by default
2014-02-14tests: turn on network daemon tests by defaultJeff King
We do not run the httpd nor git-daemon tests by default, as they are rather heavyweight and require network access (albeit over localhost). However, it would be nice if more pepole ran them, for two reasons: 1. We would get more test coverage on more systems. 2. The point of the test suite is to find regressions. It is very easy to change some of the underlying code and break the httpd code without realizing you are even affecting it. Running the httpd tests helps find these problems sooner (ideally before the patches even hit the list). We still want to leave an "out", though, for people who really do not want to run them. For that reason, the GIT_TEST_HTTPD and GIT_TEST_GIT_DAEMON variables are now tri-state booleans (true/false/auto), so you can say GIT_TEST_HTTPD=false to turn the tests back off. To support those who want a stable single way to disable these tests across versions of Git before and after this change, an empty string explicitly set to these variables is also taken as "false", so the behaviour changes only for those who: a. did not express any preference by leaving these variables unset. They did not test these features before, but now they do; or b. did express that they want to test these features by setting GIT_TEST_FEATURE=false (or any equivalent other ways to tell "false" to Git, e.g. "0"), which has been a valid but funny way to say that they do want to test the feature only because we used to interpret any non-empty string to mean "yes please test". They no longer test that feature. In addition, we are forgiving of common setup failures (e.g., you do not have apache installed, or have an old version) when the tri-state is "auto" (or unset), but report an error when it is "true". This makes "auto" a sane default, as we should not cause failures on setups where the tests cannot run. But it allows people who use "true" to catch regressions in their system (e.g., they uninstalled apache, but were expecting their automated test runs to test git-httpd, and would want to be notified). Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2014-02-10tests: auto-set git-daemon portJeff King
A recent commit taught lib-httpd to always start apache on the same port as the numbered tests. Let's do the same for the git-daemon tests. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2013-11-26test: replace shebangs with descriptions in shell librariesJonathan Nieder
A #! line in these files is misleading, since these scriptlets are meant to be sourced with '.' (using whatever shell sources them) instead of run directly using the interpreter named on the #! line. Removing the #! line shouldn't hurt syntax highlighting since these files have filenames ending with '.sh'. For documentation, add a brief description of how the files are meant to be used in place of the shebang line. Signed-off-by: Jonathan Nieder <> Signed-off-by: Junio C Hamano <>
2012-04-27t5570: fix forwarding of git-daemon messages via catJohannes Sixt
The shell function that starts git-daemon wants to read the first line of the daemon's stderr to ensure that it started correctly. Subsequent daemon errors should be redirected to fd 4 (which is the terminal in verbose mode or /dev/null in quiet mode). To that end the shell script used 'read' to get the first line of output, and then 'cat &' to forward everything else in a background process. The problem is, that 'cat >&4 &' does not produce any output because the shell redirects a background process's stdin to /dev/null. To have this command invocation do anything useful, we have to redirect its stdin explicitly (which overrides the /dev/null redirection). The shell function connects the daemon's stderr to its consumers via a FIFO. We cannot just do this: read line <git_daemon_output cat <git_daemon_output >&4 & because after the first redirection the pipe is closed and the daemon could receive SIGPIPE if it writes at the wrong moment. Therefore, we open the readable end of the FIFO only once on fd 7 in the shell and dup from there to the stdin of the two consumers. Signed-off-by: Johannes Sixt <> Acked-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2012-01-08git-daemon tests: wait until daemon is readyClemens Buchacher
In start_daemon, git-daemon is started as a background process. In theory, the tests may try to connect before the daemon had a chance to open a listening socket. Avoid this race condition by waiting for it to output "Ready to rumble". Any other output is considered an error and the test is aborted. Should git-daemon produce no output at all, lib-git-daemon would block forever. This could be fixed by introducing a timeout. On the other hand, we have no timeout for other git commands which could suffer from the same problem. Since such a mechanism adds some complexity, I have decided against it. Signed-off-by: Clemens Buchacher <> Signed-off-by: Junio C Hamano <>
2012-01-08git-daemon: add testsClemens Buchacher
The semantics of the git daemon tests are similar to the http transport tests. In fact, they are only a slightly modified copy of t5550, plus the newly added remote error tests. All git-daemon tests will be skipped unless the environment variable GIT_TEST_GIT_DAEMON is set. Signed-off-by: Clemens Buchacher <> Helped-by: Jeff King <> Signed-off-by: Junio C Hamano <>