From: Lars Schneider <redacted>
diff to v4:
* add Junio's "test_must_fail ok=" refactor that he sent as response
to my patch. Did I attribute this to Junio in the right way by adding
"Signed-off-by: Junio C Hamano [off-list ref]" to the commit message?
Please let me know how to handle these cases properly!
* fix commit message wording according to Junio's suggestion
* do not accept sigpipe failures in "git cat-file" (thanks Junio)
* reorder patches (thanks Eric)
* fix incorrect space indent (thanks Eric)
* add a trap to git-p4 tests that ensure p4d is always killed
You can see the CI results for this patch applied on master here:
https://travis-ci.org/larsxschneider/git/builds/91216501
Thanks,
Lars
Lars Schneider (6):
implement test_might_fail using a refactored test_must_fail
add "ok=sigpipe" to test_must_fail and use it to fix flaky tests
git-p4: retry kill/cleanup operations in tests with timeout
git-p4: add p4d timeout in tests
git-p4: add trap to kill p4d on test exit
Add Travis CI support
.travis.yml | 131 ++++++++++++++++++++++++++++++++++++++++
t/lib-git-p4.sh | 57 ++++++++++++++---
t/t5504-fetch-receive-strict.sh | 3 +-
t/t5516-fetch-push.sh | 6 +-
t/test-lib-functions.sh | 39 +++++++-----
5 files changed, 207 insertions(+), 29 deletions(-)
create mode 100644 .travis.yml
--
2.5.1
From: Lars Schneider <redacted>
Add an (optional) first parameter "ok=<special case>" to test_must_fail
and return success for "<special case>". Add "success" as
"<special case>" and use it to implement "test_might_fail". This removes
redundancies in test-lib-function.sh.
Signed-off-by: Junio C Hamano <redacted>
Signed-off-by: Lars Schneider <redacted>
---
t/test-lib-functions.sh | 35 ++++++++++++++++++++---------------
1 file changed, 20 insertions(+), 15 deletions(-)
@@ -582,18 +582,32 @@ test_line_count () {# the failure could be due to a segv. We want a controlled failure. test_must_fail(){+case"$1"in+ok=*)+_test_ok=${1#ok=}+shift+;;+*)+_test_ok=+;;+esac"$@"exit_code=$?-iftest$exit_code=0;then+if!case",$_test_ok,"in*,success,*)false;;esac&&+test$exit_code=0+thenecho>&2"test_must_fail: command succeeded: $*"-return1-eliftest$exit_code-gt129&&test$exit_code-le192;then+return0+eliftest$exit_code-gt129&&test$exit_code-le192+thenecho>&2"test_must_fail: died by signal: $*"return1-eliftest$exit_code=127;then+eliftest$exit_code=127+thenecho>&2"test_must_fail: command not found: $*"return1-eliftest$exit_code=126;then+eliftest$exit_code=126+thenecho>&2"test_must_fail: valgrind error: $*"return1fi
@@ -612,16 +626,7 @@ test_must_fail () {# because we want to notice if it fails due to segv. test_might_fail(){-"$@"-exit_code=$?-iftest$exit_code-gt129&&test$exit_code-le192;then-echo>&2"test_might_fail: died by signal: $*"-return1-eliftest$exit_code=127;then-echo>&2"test_might_fail: command not found: $*"-return1-fi-return0+test_must_failok=success"$@"}# Similar to test_must_fail and test_might_fail, but check that a
From: Lars Schneider <redacted>
In rare cases kill/cleanup operations in tests fail. Retry these
operations with a timeout to make the test less flaky.
Signed-off-by: Lars Schneider <redacted>
---
t/lib-git-p4.sh | 31 +++++++++++++++++++++++--------
1 file changed, 23 insertions(+), 8 deletions(-)
@@ -6,6 +6,10 @@# a subdirectory called "$git"TEST_NO_CREATE_REPO=NoThanks+# Some operations require multiple attempts to be successful. Define+# here the maximal retry timeout in seconds.+RETRY_TIMEOUT=60+ ../test-lib.shif!test_have_prereqPYTHON
@@ -121,22 +125,33 @@ p4_add_user() {EOF}+retry_until_success(){+timeout=$(($(date+%s)+$RETRY_TIMEOUT))+until"$@"2>/dev/null||test$(date+%s)-gt$timeout+do:+done+}++retry_until_fail(){+timeout=$(($(date+%s)+$RETRY_TIMEOUT))+until!"$@"2>/dev/null||test$(date+%s)-gt$timeout+do:+done+}+ kill_p4d(){pid=$(cat"$pidfile")-# it had better exist for the first kill-kill$pid&&-foriin12345;do-kill$pid>/dev/null2>&1||break-sleep1-done&&+retry_until_failkill$pid+retry_until_failkill-9$pid# complain if it would not dietest_must_failkill$pid>/dev/null2>&1&&rm-rf"$db""$cli""$pidfile"} cleanup_git(){-rm-rf"$git"&&-mkdir"$git"+retry_until_successrm-r"$git"+test_must_failtest-d"$git"&&+retry_until_successmkdir"$git"} marshal_dump(){
From: Lars Schneider <redacted>
The tests are currently executed on "Ubuntu 12.04 LTS Server Edition
64 bit" and on "OS X Mavericks" using gcc and clang.
Perforce and Git-LFS are installed and therefore available for the
respective tests.
Signed-off-by: Lars Schneider <redacted>
---
.travis.yml | 131 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 131 insertions(+)
create mode 100644 .travis.yml
From: Lars Schneider <redacted>
t5516 "75 - deny fetch unreachable SHA1, allowtipsha1inwant=true" is
flaky in the following case:
1. remote upload-pack finds out "not our ref"
2. remote sends a response and closes the pipe
3. fetch-pack still tries to write commands to the remote upload-pack
4. write call in wrapper.c dies with SIGPIPE
t5504 "9 - push with transfer.fsckobjects" is flaky, too, and returns
SIGPIPE once in a while. I had to remove the final "To dst..." output
check because there is no output if the process dies with SIGPUPE.
Accept such a death-with-sigpipe also as OK when we are expecting a
failure.
Signed-off-by: Lars Schneider <redacted>
---
t/t5504-fetch-receive-strict.sh | 3 +--
t/t5516-fetch-push.sh | 6 +++---
t/test-lib-functions.sh | 4 ++++
3 files changed, 8 insertions(+), 5 deletions(-)
From: Lars Schneider <redacted>
In rare cases p4d seems to hang. This watchdog will kill the p4d
process after 300s in any case. That means each individual git p4 test
needs to finish before 300s or it will fail.
Signed-off-by: Lars Schneider <redacted>
---
t/lib-git-p4.sh | 20 +++++++++++++++++++-
1 file changed, 19 insertions(+), 1 deletion(-)
@@ -10,6 +10,10 @@ TEST_NO_CREATE_REPO=NoThanks# here the maximal retry timeout in seconds.RETRY_TIMEOUT=60+# Sometimes p4d seems to hang. Terminate the p4d process automatically after+# the defined timeout in seconds.+P4D_TIMEOUT=300+ ../test-lib.shif!test_have_prereqPYTHON
@@ -85,6 +89,19 @@ start_p4d() {# will be caught with the "kill -0" check below.i=${P4D_START_PATIENCE:-300}pid=$(cat"$pidfile")++timeout=$(($(date+%s)+$P4D_TIMEOUT))+whiletrue+do+iftest$(date+%s)-gt$timeout+then+kill-9$pid+exit1+fi+sleep1+done&+watchdog_pid=$!+ready=whiletest$i-gt0do
@@ -145,7 +162,8 @@ kill_p4d() {retry_until_failkill-9$pid# complain if it would not dietest_must_failkill$pid>/dev/null2>&1&&-rm-rf"$db""$cli""$pidfile"+rm-rf"$db""$cli""$pidfile"&&+retry_until_failkill-9$watchdog_pid} cleanup_git(){
From: Lars Schneider <redacted>
Sometimes the "prove" test runner hangs on test exit because p4d is
still running. Add a trap to always kill "p4d" on test exit.
You can reproduce the problem by commenting "P4D_TIMEOUT" in
"lib-git-p4.sh" and running "prove ./t9800-git-p4-basic.sh".
---
t/lib-git-p4.sh | 6 ++++++
1 file changed, 6 insertions(+)
@@ -65,6 +65,12 @@ cli="$TRASH_DIRECTORY/cli"git="$TRASH_DIRECTORY/git"pidfile="$TRASH_DIRECTORY/p4d.pid"+# Sometimes "prove" seems to hang on exit because p4d is still running+cleanup(){+kill-9$(cat"$pidfile")2>/dev/null&&exit255+}+trapcleanupEXIT+# git p4 submit generates a temp file, which will# not get cleaned up if the submission fails. Don't# clutter up /tmp on the test machine.
From: Luke Diamand <hidden> Date: 2016-06-15 23:07:15
On 15/11/15 13:08, larsxschneider@gmail.com wrote:
From: Lars Schneider <redacted>
In rare cases kill/cleanup operations in tests fail. Retry these
operations with a timeout to make the test less flaky.
Should there be a sleep in that retry_until_success loop so that it
doesn't spin sending signals to p4d?
Do we need to worry about the time offset being updated (e.g. NTP) while
this is running?
@@ -6,6 +6,10 @@# a subdirectory called "$git"TEST_NO_CREATE_REPO=NoThanks+# Some operations require multiple attempts to be successful. Define+# here the maximal retry timeout in seconds.+RETRY_TIMEOUT=60+../test-lib.shif!test_have_prereqPYTHON
From: Luke Diamand <hidden> Date: 2016-06-15 23:07:15
On 15/11/15 13:08, larsxschneider@gmail.com wrote:
From: Lars Schneider <redacted>
In rare cases p4d seems to hang. This watchdog will kill the p4d
process after 300s in any case. That means each individual git p4 test
needs to finish before 300s or it will fail.
@@ -10,6 +10,10 @@ TEST_NO_CREATE_REPO=NoThanks# here the maximal retry timeout in seconds.RETRY_TIMEOUT=60+# Sometimes p4d seems to hang. Terminate the p4d process automatically after+# the defined timeout in seconds.+P4D_TIMEOUT=300+../test-lib.shif!test_have_prereqPYTHON
@@ -85,6 +89,19 @@ start_p4d() {# will be caught with the "kill -0" check below.i=${P4D_START_PATIENCE:-300}pid=$(cat"$pidfile")++timeout=$(($(date+%s)+$P4D_TIMEOUT))+whiletrue+do+iftest$(date+%s)-gt$timeout+then+kill-9$pid+exit1+fi+sleep1+done&+watchdog_pid=$!+ready=whiletest$i-gt0do
@@ -145,7 +162,8 @@ kill_p4d() {retry_until_failkill-9$pid# complain if it would not dietest_must_failkill$pid>/dev/null2>&1&&-rm-rf"$db""$cli""$pidfile"+rm-rf"$db""$cli""$pidfile"&&+retry_until_failkill-9$watchdog_pid}cleanup_git(){
From: Luke Diamand <hidden> Date: 2016-06-15 23:07:15
On 15/11/15 13:08, larsxschneider@gmail.com wrote:
From: Lars Schneider <redacted>
Sometimes the "prove" test runner hangs on test exit because p4d is
still running. Add a trap to always kill "p4d" on test exit.
With this change, I've started seeing this when running the tests:
cat: /home/lgd/git/git/t/trash
directory.t9819-git-p4-case-folding/p4d.pid: No such file or directory
Probably just needs the obvious "test -f" adding.
Other than, all looks good to me. Particularly nice that I can now do:
$ make T=t98* -j10
and it actually works!
quoted hunk
You can reproduce the problem by commenting "P4D_TIMEOUT" in
"lib-git-p4.sh" and running "prove ./t9800-git-p4-basic.sh".
---
t/lib-git-p4.sh | 6 ++++++
1 file changed, 6 insertions(+)
@@ -65,6 +65,12 @@ cli="$TRASH_DIRECTORY/cli"git="$TRASH_DIRECTORY/git"pidfile="$TRASH_DIRECTORY/p4d.pid"+# Sometimes "prove" seems to hang on exit because p4d is still running+cleanup(){+kill-9$(cat"$pidfile")2>/dev/null&&exit255+}+trapcleanupEXIT+# git p4 submit generates a temp file, which will# not get cleaned up if the submission fails. Don't# clutter up /tmp on the test machine.
From: Eric Sunshine <hidden> Date: 2016-06-15 23:07:15
On Sun, Nov 15, 2015 at 8:08 AM, [off-list ref] wrote:
quoted hunk
From: Lars Schneider <redacted>
In rare cases kill/cleanup operations in tests fail. Retry these
operations with a timeout to make the test less flaky.
Signed-off-by: Lars Schneider <redacted>
---
There was some discussion previously[1] about detecting dynamically
whether 'date +%s' was supported. Was this something that you intended
to do, or did you decide against it since p4 is not supported on such
platforms?
Same question also applies to patch 4/6.
[1]: http://article.gmane.org/gmane.comp.version-control.git/280978/match=lazy+prerequisite
+ until "$@" 2>/dev/null || test $(date +%s) -gt $timeout
+ do :
+ done
+}
+
+retry_until_fail() {
+ timeout=$(($(date +%s) + $RETRY_TIMEOUT))
+ until ! "$@" 2>/dev/null || test $(date +%s) -gt $timeout
+ do :
+ done
+}
From: Lars Schneider <hidden> Date: 2016-06-15 23:07:16
On 16 Nov 2015, at 09:36, Luke Diamand [off-list ref] wrote:
On 15/11/15 13:08, larsxschneider@gmail.com wrote:
quoted
From: Lars Schneider <redacted>
In rare cases kill/cleanup operations in tests fail. Retry these
operations with a timeout to make the test less flaky.
Should there be a sleep in that retry_until_success loop so that it doesn't spin sending signals to p4d?
Agreed. I will add a sleep in the next roll!
Do we need to worry about the time offset being updated (e.g. NTP) while this is running?
Interesting question! I would consider this an edge case but I can see how it could happen.
Do you see a way to handle that in an easy way?
Thanks,
Lars
@@ -6,6 +6,10 @@# a subdirectory called "$git"TEST_NO_CREATE_REPO=NoThanks+# Some operations require multiple attempts to be successful. Define+# here the maximal retry timeout in seconds.+RETRY_TIMEOUT=60+ ../test-lib.shif!test_have_prereqPYTHON
From: Lars Schneider <hidden> Date: 2016-06-15 23:07:16
On 16 Nov 2015, at 22:14, Eric Sunshine [off-list ref] wrote:
On Sun, Nov 15, 2015 at 8:08 AM, [off-list ref] wrote:
quoted
From: Lars Schneider <redacted>
In rare cases kill/cleanup operations in tests fail. Retry these
operations with a timeout to make the test less flaky.
Signed-off-by: Lars Schneider <redacted>
---
There was some discussion previously[1] about detecting dynamically
whether 'date +%s' was supported. Was this something that you intended
to do, or did you decide against it since p4 is not supported on such
platforms?
Same question also applies to patch 4/6.
While implementing it I thought more about it. P4D is only supported on platforms that support the date function. That means these tests will only run on platforms that support the date function. Consequently I wondered if this would justify the slightly more complicated code. However, if you think this change would help the patch to get accepted then I will add it.
Thanks,
Lars
From: Lars Schneider <hidden> Date: 2016-06-15 23:07:16
On 16 Nov 2015, at 09:43, Luke Diamand [off-list ref] wrote:
On 15/11/15 13:08, larsxschneider@gmail.com wrote:
quoted
From: Lars Schneider <redacted>
Sometimes the "prove" test runner hangs on test exit because p4d is
still running. Add a trap to always kill "p4d" on test exit.
With this change, I've started seeing this when running the tests:
cat: /home/lgd/git/git/t/trash directory.t9819-git-p4-case-folding/p4d.pid: No such file or directory
Probably just needs the obvious "test -f" adding.
Other than, all looks good to me. Particularly nice that I can now do:
$ make T=t98* -j10
and it actually works!
Great! I can see where the cat error comes from. I will add the "test -f" condition in the next roll.
Thanks,
Lars
quoted
You can reproduce the problem by commenting "P4D_TIMEOUT" in
"lib-git-p4.sh" and running "prove ./t9800-git-p4-basic.sh".
---
t/lib-git-p4.sh | 6 ++++++
1 file changed, 6 insertions(+)
@@ -65,6 +65,12 @@ cli="$TRASH_DIRECTORY/cli"git="$TRASH_DIRECTORY/git"pidfile="$TRASH_DIRECTORY/p4d.pid"+# Sometimes "prove" seems to hang on exit because p4d is still running+cleanup(){+kill-9$(cat"$pidfile")2>/dev/null&&exit255+}+trapcleanupEXIT+# git p4 submit generates a temp file, which will# not get cleaned up if the submission fails. Don't# clutter up /tmp on the test machine.
From: Eric Sunshine <hidden> Date: 2016-06-15 23:07:16
On Tue, Nov 17, 2015 at 3:28 AM, Lars Schneider
[off-list ref] wrote:
On 16 Nov 2015, at 22:14, Eric Sunshine [off-list ref] wrote:
quoted
On Sun, Nov 15, 2015 at 8:08 AM, [off-list ref] wrote:
quoted
From: Lars Schneider <redacted>
In rare cases kill/cleanup operations in tests fail. Retry these
operations with a timeout to make the test less flaky.
Signed-off-by: Lars Schneider <redacted>
---
There was some discussion previously[1] about detecting dynamically
whether 'date +%s' was supported. Was this something that you intended
to do, or did you decide against it since p4 is not supported on such
platforms?
Same question also applies to patch 4/6.
While implementing it I thought more about it. P4D is only
supported on platforms that support the date function. That means
these tests will only run on platforms that support the date
function. Consequently I wondered if this would justify the
slightly more complicated code. However, if you think this change
would help the patch to get accepted then I will add it.
I don't feel strongly about it, and it's not my call anyhow. Opinions
of Junio, Peff (as interim maintainer), and Luke weigh much more
heavily than my own. Punting on dynamic detection of "date +%s" may be
perfectly acceptable with the attitude that it can be implemented
later if someone runs across a case where it's actually needed.
From: Luke Diamand <hidden> Date: 2016-06-15 23:07:16
quoted
While implementing it I thought more about it. P4D is only
supported on platforms that support the date function. That means
these tests will only run on platforms that support the date
function. Consequently I wondered if this would justify the
slightly more complicated code. However, if you think this change
would help the patch to get accepted then I will add it.
I don't feel strongly about it, and it's not my call anyhow. Opinions
of Junio, Peff (as interim maintainer), and Luke weigh much more
heavily than my own. Punting on dynamic detection of "date +%s" may be
perfectly acceptable with the attitude that it can be implemented
later if someone runs across a case where it's actually needed.
Which other platforms are we talking about here?
https://www.perforce.com/downloads/helix
From there, you can get Solaris10, HP-UX, AIX and various flavours of
BSD. Solaris supports "date +%s".
HP-UX and AIX, I really don't know.
Windows? I assume 'date +%s' will work for people using mingw.
Is it possible to get the time in seconds by doing something like this:
time_in_seconds() {
python -c 'import time; print time.time()'
}
Luke
From: Luke Diamand <hidden> Date: 2016-06-15 23:07:16
On 17/11/15 08:22, Lars Schneider wrote:
On 16 Nov 2015, at 09:36, Luke Diamand [off-list ref] wrote:
quoted
On 15/11/15 13:08, larsxschneider@gmail.com wrote:
quoted
From: Lars Schneider <redacted>
In rare cases kill/cleanup operations in tests fail. Retry these
operations with a timeout to make the test less flaky.
Should there be a sleep in that retry_until_success loop so that it doesn't spin sending signals to p4d?
Agreed. I will add a sleep in the next roll!
quoted
Do we need to worry about the time offset being updated (e.g. NTP) while this is running?
Interesting question! I would consider this an edge case but I can see how it could happen.
Do you see a way to handle that in an easy way?
You want to somehow call clock_gettime(CLOCK_MONOTONIC). That's not in
python until 3.3. Writing a C program seems like overkill but could be a
solution if this becomes a problem.
From: Eric Sunshine <hidden> Date: 2016-06-15 23:07:16
On Tue, Nov 17, 2015 at 4:34 AM, Luke Diamand [off-list ref] wrote:
quoted
quoted
While implementing it I thought more about it. P4D is only
supported on platforms that support the date function. That means
these tests will only run on platforms that support the date
function. Consequently I wondered if this would justify the
slightly more complicated code. However, if you think this change
would help the patch to get accepted then I will add it.
I don't feel strongly about it, and it's not my call anyhow. Opinions
of Junio, Peff (as interim maintainer), and Luke weigh much more
heavily than my own. Punting on dynamic detection of "date +%s" may be
perfectly acceptable with the attitude that it can be implemented
later if someone runs across a case where it's actually needed.
Which other platforms are we talking about here?
https://www.perforce.com/downloads/helix
From there, you can get Solaris10, HP-UX, AIX and various flavours of BSD.
Solaris supports "date +%s".
From: Luke Diamand <hidden> Date: 2016-06-15 23:07:16
quoted
Which other platforms are we talking about here?
https://www.perforce.com/downloads/helix
From there, you can get Solaris10, HP-UX, AIX and various flavours of BSD.
Solaris supports "date +%s".