On Tue, Feb 13, 2018 at 07:27:58AM +0700, Duy Nguyen wrote:
> > Makes sense to try to make sure that we don't regress leak-free tests. I
> > don't know what our Travis-budget looks like, but I would volunteer to
> > run something like this periodically using my own cycles.
> >
> > My experience with the innards of our Makefiles and test-lib.sh is
> > non-existant, but from a very cursory look it seems like something as
> > simple as loading GIT_SKIP_TESTS from a blacklist-file might do the
> > trick.
>
> Yeah my first throught was something along that line too. But maybe
> it's nicer to mark a test file leak-free like this:
>
> -- 8< --
> diff --git a/t/t2028-worktree-move.sh b/t/t2028-worktree-move.sh
> index 459f676683..1446f075b7 100755
> --- a/t/t2028-worktree-move.sh
> +++ b/t/t2028-worktree-move.sh
> @@ -2,6 +2,8 @@
>
> test_description='test git worktree move, remove, lock and unlock'
>
> +test_leak_free=yes
> +
> . ./test-lib.sh
>
> test_expect_success 'setup' '
> -- 8< --
Hmm. That is not too bad, but somehow it feels funny to me to be
polluting each test script with these annotations. And to be driving it
from inside the test scripts.
It seems like:
make SANITIZE=leak test GIT_SKIP_TESTS="$(cat known-leaky)"
would be sufficient. And updating the list would just be:
# assume we're using prove, which will keep running after failure,
# and will record the results for us to parse (using "--state=").
# Otherwise use "make -k" and grep in t/test-results.
make SANITIZE=leak test
(cd t && prove --dry --state=failed) |
perl -lne '/^(t[0-9]{4})-.*.sh$/ and print $1' |
sort >known-leaky
That would update both now-passing and now-failing tests. Presumably
we'd keep it checked in, so "git diff" would show you the changes.
-Peff
