git/t/lib-httpd.sh

312 lines
7.2 KiB
Bash
Raw Normal View History

# Shell library to run an HTTP server for use in tests.
# Ends the test early if httpd tests should not be run,
# for example because the user has not enabled them.
#
# Usage:
#
# . ./test-lib.sh
# . "$TEST_DIRECTORY"/lib-httpd.sh
# start_httpd
#
# test_expect_success '...' '
# ...
# '
#
# test_expect_success ...
#
# test_done
#
# Can be configured using the following variables.
#
# GIT_TEST_HTTPD enable HTTPD tests
# LIB_HTTPD_PATH web server path
# LIB_HTTPD_MODULE_PATH web server modules path
# LIB_HTTPD_PORT listening port
# LIB_HTTPD_DAV enable DAV
# LIB_HTTPD_SVN enable SVN at given location (e.g. "svn")
# LIB_HTTPD_SSL enable SSL
#
# Copyright (c) 2008 Clemens Buchacher <drizzd@aon.at>
#
if ! test_have_prereq LIBCURL
then
skip_all='skipping test, git built without http support'
test_done
fi
if test -n "$NO_EXPAT" && test -n "$LIB_HTTPD_DAV"
then
skip_all='skipping test, git built without expat support'
test_done
fi
tests: add 'test_bool_env' to catch non-bool GIT_TEST_* values 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 't0017-env-helper.sh', of course). $ GIT_TEST_GIT_DAEMON=YesPlease ./t5570-git-daemon.sh 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 <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-22 13:14:36 +00:00
if ! test_bool_env GIT_TEST_HTTPD true
then
tests: turn on network daemon tests by default 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 <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-02-10 21:29:37 +00:00
skip_all="Network testing disabled (unset GIT_TEST_HTTPD to enable)"
test_done
fi
if ! test_have_prereq NOT_ROOT; then
test_skip_or_die GIT_TEST_HTTPD \
"Cannot run httpd tests as root"
fi
HTTPD_PARA=""
for DEFAULT_HTTPD_PATH in '/usr/sbin/httpd' '/usr/sbin/apache2'
do
if test -x "$DEFAULT_HTTPD_PATH"
then
break
fi
done
for DEFAULT_HTTPD_MODULE_PATH in '/usr/libexec/apache2' \
'/usr/lib/apache2/modules' \
'/usr/lib64/httpd/modules' \
'/usr/lib/httpd/modules'
do
if test -d "$DEFAULT_HTTPD_MODULE_PATH"
then
break
fi
done
case $(uname) in
Darwin)
HTTPD_PARA="$HTTPD_PARA -DDarwin"
;;
esac
LIB_HTTPD_PATH=${LIB_HTTPD_PATH-"$DEFAULT_HTTPD_PATH"}
test-lib-functions: introduce the 'test_set_port' helper function 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 't0410-partial-clone.sh' 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: - 'lib-git-p4.sh' 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/lib-git-svn.sh: improve svnserve tests with parallel make test, 2017-12-01). Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-05 01:08:58 +00:00
test_set_port LIB_HTTPD_PORT
TEST_PATH="$TEST_DIRECTORY"/lib-httpd
HTTPD_ROOT_PATH="$PWD"/httpd
HTTPD_DOCUMENT_ROOT_PATH=$HTTPD_ROOT_PATH/www
# hack to suppress apache PassEnv warnings
GIT_VALGRIND=$GIT_VALGRIND; export GIT_VALGRIND
GIT_VALGRIND_OPTIONS=$GIT_VALGRIND_OPTIONS; export GIT_VALGRIND_OPTIONS
GIT_TEST_SIDEBAND_ALL=$GIT_TEST_SIDEBAND_ALL; export GIT_TEST_SIDEBAND_ALL
GIT_TRACE=$GIT_TRACE; export GIT_TRACE
if ! test -x "$LIB_HTTPD_PATH"
then
test_skip_or_die GIT_TEST_HTTPD "no web server found at '$LIB_HTTPD_PATH'"
fi
HTTPD_VERSION=$($LIB_HTTPD_PATH -v | \
sed -n 's/^Server version: Apache\/\([0-9]*\)\..*$/\1/p; q')
if test -n "$HTTPD_VERSION"
then
if test -z "$LIB_HTTPD_MODULE_PATH"
then
if ! test $HTTPD_VERSION -ge 2
then
test_skip_or_die GIT_TEST_HTTPD \
tests: turn on network daemon tests by default 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 <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-02-10 21:29:37 +00:00
"at least Apache version 2 is required"
fi
if ! test -d "$DEFAULT_HTTPD_MODULE_PATH"
then
test_skip_or_die GIT_TEST_HTTPD \
tests: turn on network daemon tests by default 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 <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-02-10 21:29:37 +00:00
"Apache module directory not found"
fi
LIB_HTTPD_MODULE_PATH="$DEFAULT_HTTPD_MODULE_PATH"
fi
else
test_skip_or_die GIT_TEST_HTTPD \
tests: turn on network daemon tests by default 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 <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-02-10 21:29:37 +00:00
"Could not identify web server at '$LIB_HTTPD_PATH'"
fi
install_script () {
write_script "$HTTPD_ROOT_PATH/$1" <"$TEST_PATH/$1"
}
prepare_httpd() {
mkdir -p "$HTTPD_DOCUMENT_ROOT_PATH"
cp "$TEST_PATH"/passwd "$HTTPD_ROOT_PATH"
install_script incomplete-length-upload-pack-v2-http.sh
install_script incomplete-body-upload-pack-v2-http.sh
send-pack: complain about "expecting report" with --helper-status When pushing to a server which erroneously omits the final ref-status report, the client side should complain about the refs for which we didn't receive the status (because we can't just assume they were updated). This works over most transports like ssh, but for http we'll print a very misleading "Everything up-to-date". It works for ssh because send-pack internally sets the status of each ref to REF_STATUS_EXPECTING_REPORT, and then if the server doesn't tell us about a particular ref, it will stay at that value. When we print the final status table, we'll see that we're still on EXPECTING_REPORT and complain then. But for http, we go through remote-curl, which invokes send-pack with "--stateless-rpc --helper-status". The latter option causes send-pack to return a machine-readable list of ref statuses to the remote helper. But ever since its inception in de1a2fdd38 (Smart push over HTTP: client side, 2009-10-30), the send-pack code has simply omitted mention of any ref which ended up in EXPECTING_REPORT. In the remote helper, we then take the absence of any status report from send-pack to mean that the ref was not even something we tried to send, and thus it prints "Everything up-to-date". Fortunately it does detect the eventual non-zero exit from send-pack, and propagates that in its own non-zero exit code. So at least a careful script invoking "git push" would notice the failure. But sending the misleading message on stderr is certainly confusing for humans (not to mention the machine-readable "push --porcelain" output, though again, any careful script should be checking the exit code from push, too). Nobody seems to have noticed because the server in this instance has to be misbehaving: it has promised to support the ref-status capability (otherwise the client will not set EXPECTING_REPORT at all), but didn't send us any. If the connection were simply cut, then send-pack would complain about getting EOF while trying to read the status. But if the server actually sends a flush packet (i.e., saying "now you have all of the ref statuses" without actually sending any), then the client ends up in this confused situation. The fix is simple: we should return an error message from "send-pack --helper-status", just like we would for any other error per-ref error condition (in the test I included, the server simply omits all ref status responses, but a more insidious version of this would skip only some of them). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-18 19:43:47 +00:00
install_script error-no-report.sh
install_script broken-smart-http.sh
install_script error-smart-http.sh
install_script error.sh
t/lib-httpd: avoid using macOS' sed Among other differences relative to GNU sed, macOS' sed always ends its output with a trailing newline, even if the input did not have such a trailing newline. Surprisingly, this makes three httpd-based tests fail on macOS: t5616, t5702 and t5703. ("Surprisingly" because those tests have been around for some time, but apparently nobody runs them on macOS with a working Apache2 setup.) The reason is that we use `sed` in those tests to filter the response of the web server. Apart from the fact that we use GNU constructs (such as using a space after the `c` command instead of a backslash and a newline), we have another problem: macOS' sed LF-only newlines while webservers are supposed to use CR/LF ones. Even worse, t5616 uses `sed` to replace a binary part of the response with a new binary part (kind of hoping that the replaced binary part does not contain a 0x0a byte which would be interpreted as a newline). To that end, it calls on Perl to read the binary pack file and hex-encode it, then calls on `sed` to prefix every hex digit pair with a `\x` in order to construct the text that the `c` statement of the `sed` invocation is supposed to insert. So we call Perl and sed to construct a sed statement. The final nail in the coffin is that macOS' sed does not even interpret those `\x<hex>` constructs. Let's just replace all of that by Perl snippets. With Perl, at least, we do not have to deal with GNU vs macOS semantics, we do not have to worry about unwanted trailing newlines, and we do not have to spawn commands to construct arguments for other commands to be spawned (i.e. we can avoid a whole lot of shell scripting complexity). The upshot is that this fixes t5616, t5702 and t5703 on macOS with Apache2. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-27 13:23:11 +00:00
install_script apply-one-time-perl.sh
ln -s "$LIB_HTTPD_MODULE_PATH" "$HTTPD_ROOT_PATH/modules"
if test -n "$LIB_HTTPD_SSL"
then
HTTPD_PROTO=https
RANDFILE_PATH="$HTTPD_ROOT_PATH"/.rnd openssl req \
-config "$TEST_PATH/ssl.cnf" \
-new -x509 -nodes \
-out "$HTTPD_ROOT_PATH/httpd.pem" \
-keyout "$HTTPD_ROOT_PATH/httpd.pem"
GIT_SSL_NO_VERIFY=t
export GIT_SSL_NO_VERIFY
HTTPD_PARA="$HTTPD_PARA -DSSL"
else
HTTPD_PROTO=http
fi
HTTPD_DEST=127.0.0.1:$LIB_HTTPD_PORT
HTTPD_URL=$HTTPD_PROTO://$HTTPD_DEST
HTTPD_URL_USER=$HTTPD_PROTO://user%40host@$HTTPD_DEST
HTTPD_URL_USER_PASS=$HTTPD_PROTO://user%40host:pass%40host@$HTTPD_DEST
if test -n "$LIB_HTTPD_DAV" || test -n "$LIB_HTTPD_SVN"
then
HTTPD_PARA="$HTTPD_PARA -DDAV"
if test -n "$LIB_HTTPD_SVN"
then
HTTPD_PARA="$HTTPD_PARA -DSVN"
LIB_HTTPD_SVNPATH="$rawsvnrepo"
svnrepo="http://127.0.0.1:$LIB_HTTPD_PORT/"
svnrepo="$svnrepo$LIB_HTTPD_SVN"
export LIB_HTTPD_SVN LIB_HTTPD_SVNPATH
fi
fi
}
start_httpd() {
prepare_httpd >&3 2>&4
test_atexit stop_httpd
"$LIB_HTTPD_PATH" -d "$HTTPD_ROOT_PATH" \
-f "$TEST_PATH/apache.conf" $HTTPD_PARA \
-c "Listen 127.0.0.1:$LIB_HTTPD_PORT" -k start \
>&3 2>&4
if test $? -ne 0
then
cat "$HTTPD_ROOT_PATH"/error.log >&4 2>/dev/null
test_skip_or_die GIT_TEST_HTTPD "web server setup failed"
fi
}
stop_httpd() {
"$LIB_HTTPD_PATH" -d "$HTTPD_ROOT_PATH" \
-f "$TEST_PATH/apache.conf" $HTTPD_PARA -k stop
}
test_http_push_nonff () {
REMOTE_REPO=$1
LOCAL_REPO=$2
BRANCH=$3
EXPECT_CAS_RESULT=${4-failure}
test_expect_success 'non-fast-forward push fails' '
cd "$REMOTE_REPO" &&
HEAD=$(git rev-parse --verify HEAD) &&
cd "$LOCAL_REPO" &&
git checkout $BRANCH &&
echo "changed" > path2 &&
git commit -a -m path2 --amend &&
test_must_fail git push -v origin >output 2>&1 &&
(cd "$REMOTE_REPO" &&
test $HEAD = $(git rev-parse --verify HEAD))
'
test_expect_success 'non-fast-forward push show ref status' '
grep "^ ! \[rejected\][ ]*$BRANCH -> $BRANCH (non-fast-forward)$" output
'
test_expect_success 'non-fast-forward push shows help message' '
test_i18ngrep "Updates were rejected because" output
'
test_expect_${EXPECT_CAS_RESULT} 'force with lease aka cas' '
HEAD=$( cd "$REMOTE_REPO" && git rev-parse --verify HEAD ) &&
test_when_finished '\''
(cd "$REMOTE_REPO" && git update-ref HEAD "$HEAD")
'\'' &&
(
cd "$LOCAL_REPO" &&
git push -v --force-with-lease=$BRANCH:$HEAD origin
) &&
git rev-parse --verify "$BRANCH" >expect &&
(
cd "$REMOTE_REPO" && git rev-parse --verify HEAD
) >actual &&
test_cmp expect actual
'
}
setup_askpass_helper() {
test_expect_success 'setup askpass helper' '
write_script "$TRASH_DIRECTORY/askpass" <<-\EOF &&
echo >>"$TRASH_DIRECTORY/askpass-query" "askpass: $*" &&
case "$*" in
*Username*)
what=user
;;
*Password*)
what=pass
;;
esac &&
cat "$TRASH_DIRECTORY/askpass-$what"
EOF
GIT_ASKPASS="$TRASH_DIRECTORY/askpass" &&
export GIT_ASKPASS &&
export TRASH_DIRECTORY
'
}
set_askpass() {
>"$TRASH_DIRECTORY/askpass-query" &&
echo "$1" >"$TRASH_DIRECTORY/askpass-user" &&
echo "$2" >"$TRASH_DIRECTORY/askpass-pass"
}
expect_askpass() {
remote-curl: rewrite base url from info/refs redirects For efficiency and security reasons, an earlier commit in this series taught http_get_* to re-write the base url based on redirections we saw while making a specific request. This commit wires that option into the info/refs request, meaning that a redirect from http://example.com/foo.git/info/refs to https://example.com/bar.git/info/refs will behave as if "https://example.com/bar.git" had been provided to git in the first place. The tests bear some explanation. We introduce two new hierearchies into the httpd test config: 1. Requests to /smart-redir-limited will work only for the initial info/refs request, but not any subsequent requests. As a result, we can confirm whether the client is re-rooting its requests after the initial contact, since otherwise it will fail (it will ask for "repo.git/git-upload-pack", which is not redirected). 2. Requests to smart-redir-auth will redirect, and require auth after the redirection. Since we are using the redirected base for further requests, we also update the credential struct, in order not to mislead the user (or credential helpers) about which credential is needed. We can therefore check the GIT_ASKPASS prompts to make sure we are prompting for the new location. Because we have neither multiple servers nor https support in our test setup, we can only redirect between paths, meaning we need to turn on credential.useHttpPath to see the difference. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
2013-09-28 08:35:35 +00:00
dest=$HTTPD_DEST${3+/$3}
{
case "$1" in
none)
;;
pass)
echo "askpass: Password for 'http://$2@$dest': "
;;
both)
echo "askpass: Username for 'http://$dest': "
echo "askpass: Password for 'http://$2@$dest': "
;;
*)
false
;;
esac
} >"$TRASH_DIRECTORY/askpass-expect" &&
test_cmp "$TRASH_DIRECTORY/askpass-expect" \
"$TRASH_DIRECTORY/askpass-query"
}
strip_access_log() {
sed -e "
s/^.* \"//
s/\"//
s/ [1-9][0-9]*\$//
s/^GET /GET /
" "$HTTPD_ROOT_PATH"/access.log
}
t/lib-httpd: avoid occasional failures when checking access.log The last test of 't5561-http-backend.sh', 'server request log matches test results' may fail occasionally, because the order of entries in Apache's access log doesn't match the order of requests sent in the previous tests, although all the right requests are there. I saw it fail on Travis CI five times in the span of about half a year, when the order of two subsequent requests was flipped, and could trigger the failure with a modified Git. However, I was unable to trigger it with stock Git on my machine. Three tests in 't5541-http-push-smart.sh' and 't5551-http-fetch-smart.sh' check requests in the log the same way, so they might be prone to a similar occasional failure as well. When a test sends a HTTP request, it can continue execution after 'git-http-backend' fulfilled that request, but Apache writes the corresponding access log entry only after 'git-http-backend' exited. Some time inevitably passes between fulfilling the request and writing the log entry, and, under unfavourable circumstances, enough time might pass for the subsequent request to be sent and fulfilled by a different Apache thread or process, and then Apache writes access log entries racily. This effect can be exacerbated by adding a bit of variable delay after the request is fulfilled but before 'git-http-backend' exits, e.g. like this: diff --git a/http-backend.c b/http-backend.c index f3dc218b2..bbf4c125b 100644 --- a/http-backend.c +++ b/http-backend.c @@ -709,5 +709,7 @@ int cmd_main(int argc, const char **argv) max_request_buffer); cmd->imp(&hdr, cmd_arg); + if (getpid() % 2) + sleep(1); return 0; } This delay considerably increases the chances of log entries being written out of order, and in turn makes t5561's last test fail almost every time. Alas, it doesn't seem to be enough to trigger a similar failure in t5541 and t5551. So, since we can't just rely on the order of access log entries always corresponding the order of requests, make checking the access log more deterministic by sorting (simply lexicographically) both the stripped access log entries and the expected entries before the comparison with 'test_cmp'. This way the order of log entries won't matter and occasional out-of-order entries won't trigger a test failure, but the comparison will still notice any unexpected or missing log entries. OTOH, this sorting will make it harder to identify from which test an unexpected log entry came from or which test's request went missing. Therefore, in case of an error include the comparison of the unsorted log enries in the test output as well. And since all this should be performed in four tests in three test scripts, put this into a new helper function 'check_access_log' in 't/lib-httpd.sh'. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-12 12:22:16 +00:00
# Requires one argument: the name of a file containing the expected stripped
# access log entries.
check_access_log() {
sort "$1" >"$1".sorted &&
strip_access_log >access.log.stripped &&
sort access.log.stripped >access.log.sorted &&
if ! test_cmp "$1".sorted access.log.sorted
then
test_cmp "$1" access.log.stripped
fi
}