- Previous thread: BUG - git gui: unstage line not working on newly-added file
- Next thread: RFH - Spurious failures of t0025.34 -
- Threads sorted by date: linux-git 201007
Add the capability to send smoke reports to the Git test suite.
Currently we only notice bugs in the test suite when it's run
manually. Bugs in Git that only occur on obscure platforms or setups
that the core developers aren't using may thus go unnoticed until the
bug makes it into a release.
This series aims to change that. With it anyone that's interested in
avoiding bitrot in Git can volunteer to run a smoke tester. A smoke
tester periodically compiles the latest version of Git, runs the test
suite, and submits a report to a central server indicating how the
test run went.
A smoke tester might run something like this in cron:
#!/bin/sh
cd ~/g/git
git fetch
for branch in maint master next pu; do
git checkout origin/$i &&
make clean all &&
cd t &&
make smoke-report
done
The smoker might want to compile git with non-default flags. A script
which does that is outside the scope of this patch. But it's something
we'll want to include eventually.
What this does now is add smoke and smoke-report targets to
t/Makefile:
$ make clean smoke
rm -f -r 'trash directory'.* test-results
rm -f t????/cvsroot/CVSROOT/?*
rm -f -r valgrind/bin
rm -f .prove
perl ./harness Test Summary Report
TAP Archive created at /home/avar/g/git/t/test-results/git-smoke.tar.gz
The smoke target uses TAP::Harness::Archive to aggregate the test
results into a tarball. The tarball contains two things, the output of
every test file that was run, and a metadata file:
Tarball contents:
$ tar xzvf git-smoke.tar.gz
t0004-unwritable.sh
t0001-init.sh
t0002-gitfile.sh
t0005-signals.sh
t0000-basic.sh
t0003-attributes.sh
t0006-date.sh
meta.yml
A test report, this could also include A metadata file:
The "extra-properties" hash is where we'd stick Git-specific info,
like whether Git was compiled with gettext or the fallback regex
engine.
The entire tarball is then submitted to a central smoke
aggregator. Currently this is done with curl over HTTP, but could also
be done e.g. via E-Mail:
curl
-F architecture=ad64
-F platform=linux
-F revision="$(GIT-VERSION)"
-F report-file=@test-results/git-smoke.tar.gz
http://git.smoke.example.net/submit-report
The aggregator would make both the raw test reports available, and
might format them with a web interface. Smolder (on CPAN) is one
example of the latter. Here are smoke reports for the Rakudo project
on Smolder:
http://smolder.plusthree.com/app/projects/smoke-reports/18
TODO:
- Is this worthwhile. Are there developers / packagers / other
interested parties here who'd be interested in actually running
smoke testers? It should be really easy to set one up.
- How do I get things like PERL-PATH and uname-M from the top-level
Makefile? Currently I just hardcode e.g. "perl" and
"architecture=ad64". Maybe this needs to be a top-level target
instead?
- Set up the smoke aggregator. I was running into some issues with
smolder, but those are solvable given some time. I can run and
maintain the smoke aggregator if this gets accepted.
Signed-off-by: Ævar Arnfjörð Bjarmason
diff +test-results:
+ mkdir -p test-results
+
+-include ../GIT-VERSION-FILE
+test-results/git-smoke.tar.gz:
+ perl ./harness More majordomo info at http://vger.kernel.org/majordomo-info.html
Currently we only notice bugs in the test suite when it's run
manually. Bugs in Git that only occur on obscure platforms or setups
that the core developers aren't using may thus go unnoticed until the
bug makes it into a release.
This series aims to change that. With it anyone that's interested in
avoiding bitrot in Git can volunteer to run a smoke tester. A smoke
tester periodically compiles the latest version of Git, runs the test
suite, and submits a report to a central server indicating how the
test run went.
A smoke tester might run something like this in cron:
#!/bin/sh
cd ~/g/git
git fetch
for branch in maint master next pu; do
git checkout origin/$i &&
make clean all &&
cd t &&
make smoke-report
done
The smoker might want to compile git with non-default flags. A script
which does that is outside the scope of this patch. But it's something
we'll want to include eventually.
What this does now is add smoke and smoke-report targets to
t/Makefile:
$ make clean smoke
rm -f -r 'trash directory'.* test-results
rm -f t????/cvsroot/CVSROOT/?*
rm -f -r valgrind/bin
rm -f .prove
perl ./harness Test Summary Report
TAP Archive created at /home/avar/g/git/t/test-results/git-smoke.tar.gz
The smoke target uses TAP::Harness::Archive to aggregate the test
results into a tarball. The tarball contains two things, the output of
every test file that was run, and a metadata file:
Tarball contents:
$ tar xzvf git-smoke.tar.gz
t0004-unwritable.sh
t0001-init.sh
t0002-gitfile.sh
t0005-signals.sh
t0000-basic.sh
t0003-attributes.sh
t0006-date.sh
meta.yml
A test report, this could also include A metadata file:
The "extra-properties" hash is where we'd stick Git-specific info,
like whether Git was compiled with gettext or the fallback regex
engine.
The entire tarball is then submitted to a central smoke
aggregator. Currently this is done with curl over HTTP, but could also
be done e.g. via E-Mail:
curl
-F architecture=ad64
-F platform=linux
-F revision="$(GIT-VERSION)"
-F report-file=@test-results/git-smoke.tar.gz
http://git.smoke.example.net/submit-report
The aggregator would make both the raw test reports available, and
might format them with a web interface. Smolder (on CPAN) is one
example of the latter. Here are smoke reports for the Rakudo project
on Smolder:
http://smolder.plusthree.com/app/projects/smoke-reports/18
TODO:
- Is this worthwhile. Are there developers / packagers / other
interested parties here who'd be interested in actually running
smoke testers? It should be really easy to set one up.
- How do I get things like PERL-PATH and uname-M from the top-level
Makefile? Currently I just hardcode e.g. "perl" and
"architecture=ad64". Maybe this needs to be a top-level target
instead?
- Set up the smoke aggregator. I was running into some issues with
smolder, but those are solvable given some time. I can run and
maintain the smoke aggregator if this gets accepted.
Signed-off-by: Ævar Arnfjörð Bjarmason
diff +test-results:
+ mkdir -p test-results
+
+-include ../GIT-VERSION-FILE
+test-results/git-smoke.tar.gz:
+ perl ./harness More majordomo info at http://vger.kernel.org/majordomo-info.html
Ævar Arnfjörð Bjarmason wrote:
I'm all for it!
I think I could put a cronjob on a RHEL5.4 machine, and regularly run
it on my own openSuSE 11.3 install.
That's the only thing I found confusing about this: why are they named
as if they were shellscripts?
Also, installing TAP::Harness::Archive was a bit hairy but that's
CPAN's fault...
More majordomo info at http://vger.kernel.org/majordomo-info.html
I'm all for it!
I think I could put a cronjob on a RHEL5.4 machine, and regularly run
it on my own openSuSE 11.3 install.
That's the only thing I found confusing about this: why are they named
as if they were shellscripts?
Also, installing TAP::Harness::Archive was a bit hairy but that's
CPAN's fault...
More majordomo info at http://vger.kernel.org/majordomo-info.html
Ævar Arnfjörð Bjarmason wrote:
BTW, below is the script I have devised to automatically run the tests
under valgrind and then bisect any offenders. (It keeps exposing odd
test failures and stealing my time tracking them down...)
It gives fairly good results, but since it's also rather kludgy I want
to test and improve it a bit more before shooting for contrib (if
anything).
Note that running this will take on the order of hours at least.
MAILTO=tr@thomasrast.ch
branch="${1:-next}"
logfile="$(pwd)/bisection-log-$$"
export DIFF=dff # stupid bug
die () {
(echo "Error message: $*"; echo 'git fetch origin 2
# test if we've already done this
test "$(git rev-parse last-known-good-$branch)" = "$(git rev-parse origin/$branch)" && exit
git checkout -f origin/"$branch" 2
results="test-results.$(git describe)"
mkdir "$results"
make -j12 2make -k -j8 test 2
if [ ! -d t/"test-results" ]; then
mail -s "Valgrind-tested $branch: all good!" "$MAILTO" < "$logfile"
git tag -f last-known-good-$branch origin/$branch
rm "$logfile"
exit
fi
cd t/
cp -a test-results "$results"
( cd $results && perl -i -ne 'print unless /^==.*execve/i' *.out )
failing-normally=$(cd "$results" && grep -L '^0$' *.exit)
failing-valgrind=$(cd "$results" && grep -lE '^==[0-9]+==' *.out)
cd ..
echo "failed (normal):" $failing-normally | tee -a "$logfile"
echo "failed (valgrind):" $failing-valgrind | tee -a "$logfile"
if [ -z "$failing-normally" -a -z "$failing-valgrind" ]; then
mail -s "Valgrind-tested $branch: all good!" "$MAILTO" < "$logfile"
git tag -f last-known-good-$branch origin/$branch
rm "$logfile"
exit
fi
mail -s "Valgrind-testing $branch: starting test bisection" "$MAILTO" < "$logfile"
for test-out in $failing-valgrind; do
test="${test-out%.out}"
echo "bisecting valgrind-failing test $test"
git bisect start git bisect good last-known-good-pu last-known-good-next 2 git bisect bad origin/$branch 2 git bisect run sh -c "test ! -f t/$test.sh || { make -j12 && cd t && ./$test.sh for test-out in $failing-normally; do
test="${test-out%.exit}"
case "$failing-valgrind" in
*$test.out*)
continue
;;
esac
echo "bisecting failing test $test"
git bisect start 2 git bisect good last-known-good-pu last-known-good-pu 2 git bisect bad origin/$branch 2 git bisect run sh -c "test ! -f t/$test.sh || { make -j12 && cd t && ./$test.sh rm "$logfile"
More majordomo info at http://vger.kernel.org/majordomo-info.html
BTW, below is the script I have devised to automatically run the tests
under valgrind and then bisect any offenders. (It keeps exposing odd
test failures and stealing my time tracking them down...)
It gives fairly good results, but since it's also rather kludgy I want
to test and improve it a bit more before shooting for contrib (if
anything).
Note that running this will take on the order of hours at least.
MAILTO=tr@thomasrast.ch
branch="${1:-next}"
logfile="$(pwd)/bisection-log-$$"
export DIFF=dff # stupid bug
die () {
(echo "Error message: $*"; echo 'git fetch origin 2
# test if we've already done this
test "$(git rev-parse last-known-good-$branch)" = "$(git rev-parse origin/$branch)" && exit
git checkout -f origin/"$branch" 2
results="test-results.$(git describe)"
mkdir "$results"
make -j12 2make -k -j8 test 2
if [ ! -d t/"test-results" ]; then
mail -s "Valgrind-tested $branch: all good!" "$MAILTO" < "$logfile"
git tag -f last-known-good-$branch origin/$branch
rm "$logfile"
exit
fi
cd t/
cp -a test-results "$results"
( cd $results && perl -i -ne 'print unless /^==.*execve/i' *.out )
failing-normally=$(cd "$results" && grep -L '^0$' *.exit)
failing-valgrind=$(cd "$results" && grep -lE '^==[0-9]+==' *.out)
cd ..
echo "failed (normal):" $failing-normally | tee -a "$logfile"
echo "failed (valgrind):" $failing-valgrind | tee -a "$logfile"
if [ -z "$failing-normally" -a -z "$failing-valgrind" ]; then
mail -s "Valgrind-tested $branch: all good!" "$MAILTO" < "$logfile"
git tag -f last-known-good-$branch origin/$branch
rm "$logfile"
exit
fi
mail -s "Valgrind-testing $branch: starting test bisection" "$MAILTO" < "$logfile"
for test-out in $failing-valgrind; do
test="${test-out%.out}"
echo "bisecting valgrind-failing test $test"
git bisect start git bisect good last-known-good-pu last-known-good-next 2 git bisect bad origin/$branch 2 git bisect run sh -c "test ! -f t/$test.sh || { make -j12 && cd t && ./$test.sh for test-out in $failing-normally; do
test="${test-out%.exit}"
case "$failing-valgrind" in
*$test.out*)
continue
;;
esac
echo "bisecting failing test $test"
git bisect start 2 git bisect good last-known-good-pu last-known-good-pu 2 git bisect bad origin/$branch 2 git bisect run sh -c "test ! -f t/$test.sh || { make -j12 && cd t && ./$test.sh rm "$logfile"
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Jul 29, 2010 at 22:11, Thomas Rast wrote:
That's at least three smokers there. And since your RHEL5.4 machine
already turned up a gettext bug..
The output file names just match the test names, which in this case
are shellscripts.
This is something we can probably make really easy if we write some
supporting scripts with cpanminus + local::lib. I.e. just have a
config file like:
~/.gitsmoker:
repository = ~/g/git
data = ~/g/git-smoker
Where the git-smoker would maintain the state, dependencies etc. It
needs.
More majordomo info at http://vger.kernel.org/majordomo-info.html
That's at least three smokers there. And since your RHEL5.4 machine
already turned up a gettext bug..
The output file names just match the test names, which in this case
are shellscripts.
This is something we can probably make really easy if we write some
supporting scripts with cpanminus + local::lib. I.e. just have a
config file like:
~/.gitsmoker:
repository = ~/g/git
data = ~/g/git-smoker
Where the git-smoker would maintain the state, dependencies etc. It
needs.
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Jul 29, 2010 at 09:20:55PM +0000, Ævar Arnfjörð Bjarmason wrote:
A few of us were running automated build/tests for a while. Check out:
http://repo.or.cz/w/git/gitbuild.git
especially:
http://repo.or.cz/w/git/gitbuild.git/tree/platform
Unfortunately the SunOS and FreeBSD machines I tested on went away, so I
am not actually running anything automated anymore. Mike Ralphson was
testing on AIX, but seems to have stopped, as well.
I think these days Junio runs the test suite through a couple of VMs,
but I don't know exactly which platforms, or how often he does so.
-Peff
More majordomo info at http://vger.kernel.org/majordomo-info.html
A few of us were running automated build/tests for a while. Check out:
http://repo.or.cz/w/git/gitbuild.git
especially:
http://repo.or.cz/w/git/gitbuild.git/tree/platform
Unfortunately the SunOS and FreeBSD machines I tested on went away, so I
am not actually running anything automated anymore. Mike Ralphson was
testing on AIX, but seems to have stopped, as well.
I think these days Junio runs the test suite through a couple of VMs,
but I don't know exactly which platforms, or how often he does so.
-Peff
More majordomo info at http://vger.kernel.org/majordomo-info.html
Jeff King writes:
The normal "before push-out" procedure for me is:
- On Debian5 (x86-64 - Push the four branches and run Dothem on k.org's FC11 (x86-64).
- VMs running FC11 (i386) and FBSD80 (i386) run the same "Dothem" script,
modulo that t9xxx series of tests which take too much time are skipped,
when all four branches passes tests on my primary box successfully.
I push the result out after the four branches are Ok on my primary box and
k.org's FC11 (iow, I do not wait for VM tests to finish).
More majordomo info at http://vger.kernel.org/majordomo-info.html
The normal "before push-out" procedure for me is:
- On Debian5 (x86-64 - Push the four branches and run Dothem on k.org's FC11 (x86-64).
- VMs running FC11 (i386) and FBSD80 (i386) run the same "Dothem" script,
modulo that t9xxx series of tests which take too much time are skipped,
when all four branches passes tests on my primary box successfully.
I push the result out after the four branches are Ok on my primary box and
k.org's FC11 (iow, I do not wait for VM tests to finish).
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Jul 30, 2010 at 12:11:50AM +0200, Thomas Rast wrote:
Me too! I should be able to setup a cronjob for tests under a Windows XP
machine. Does that count as an obscure platform ? ;)
cheers Heiko
More majordomo info at http://vger.kernel.org/majordomo-info.html
Me too! I should be able to setup a cronjob for tests under a Windows XP
machine. Does that count as an obscure platform ? ;)
cheers Heiko
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, Aug 8, 2010 at 13:42, Heiko Voigt wrote:
I think it does :)
I just sent another version of the series to the list. It'd be very
useful if you could try sending a smoke report from Windows XP.
Thanks.
More majordomo info at http://vger.kernel.org/majordomo-info.html
I think it does :)
I just sent another version of the series to the list. It'd be very
useful if you could try sending a smoke report from Windows XP.
Thanks.
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, Aug 08, 2010 at 02:54:21PM +0000, Ævar Arnfjörð Bjarmason wrote:
I tried to do it yesterday but unfortunately some of the tests seem to
hang on Windows so I could not complete the report. I will try to
generate a skip list and run the smoke-report again later.
cheers Heiko
More majordomo info at http://vger.kernel.org/majordomo-info.html
I tried to do it yesterday but unfortunately some of the tests seem to
hang on Windows so I could not complete the report. I will try to
generate a skip list and run the smoke-report again later.
cheers Heiko
More majordomo info at http://vger.kernel.org/majordomo-info.html
Related Threads
- android-developers - Image Upload via HTTP POST/Google App Engine - android-developers
- Re: kern/29698: linux - patch - linux ipcs doesn'work - freebsd-emulation
- wp-hackers - pre_get_posts problem - wordpress-hackers
- status report of kirubakaran #14 of 16 - nmap-dev
- git merge - both added conflict resolution - linux-git
- PATCH 0/7 - USB: ssu100: various fixes to ssu100 driver - linux-usb
- Qt-interest - Window modality - qt-interest
- finding the ip address for dns, nslookup & etc. - debian-user
- postgis-devel - PostGIS - #562: ST_DWithin gives wrong answer - postgis-devel
- pull request: wireless-2.6 2010-08-10 - linux-netdev
- PATCHv2 1/13 - dmtimer: hwmod: OMAP4: add device names to flck nodes - linux-omap
- Haskell-cafe - Embedded scripting Language for haskell app - haskell-cafe