t/660-stamp: don't run at the same time as other tests in redo -j.

flush-cache can cause files affected by redo-stamp to get rebuilt
unnecessarily, which the test is specifically trying to validate.
Since other tests run flush-cache at random times when using -j, this
would cause random test failures.
This commit is contained in:
Avery Pennarun 2018-10-12 04:39:09 -04:00
commit aa423a723f
14 changed files with 17 additions and 4 deletions

View file

@ -6,13 +6,26 @@ if [ "$(cat 000-set-minus-e/log)" != "ok" ]; then
exit 5
fi
# builds 1xx*/all
# builds 1xx*/all to test for basic/dangerous functionality.
# We don't want to run more advanced tests if the basics don't work.
/bin/ls 1[0-9][0-9]*/all.do |
sed 's/\.do$//' |
xargs redo
110-compile/hello >&2
# builds the rest
# builds most of the rest in parallel
/bin/ls [2-9][0-9][0-9]*/all.do |
sed 's/\.do$//' |
xargs redo
# builds the tests that require non-parallel execution.
# If tests are written carefully, this should only be things that
# are checking for unnecessary extra rebuilds of some targets, which
# might happen after flush-cache.
# FIXME: a better solution might be to make flush-cache less destructive!
/bin/ls [s][0-9][0-9]*/all.do |
sed 's/\.do$//' | {
while read d; do
redo "$d"
done
}

View file

@ -1,4 +1,4 @@
rm -f stampy usestamp usestamp2 stampy.log usestamp.log usestamp2.log
rm -f bob stampy usestamp usestamp2 stampy.log usestamp.log usestamp2.log
echo one >inp
../flush-cache

View file

@ -2,4 +2,4 @@ echo $$ >>stampy.log
redo-ifchange inp bob
cat inp
cd ..
redo-stamp <660-stamp/inp
redo-stamp <s60-stamp/inp