git-annex/doc/bugs/tasty_test_limiting_broken_by_concurrency.mdwn

The changes to make `git-annex test` concurrent have
broken using eg `git-annex test -p 'concurrent get of dup key regression'`

It looks like the repo setup test is not being run, even though it's
supposed to be a dependency of the test it was limited to.
--[[Joey]]

> Oh, that seems to be a limitation of tasty. From its docs:
	
	If Test B depends on Test A, remember that either of them may be 
	filtered out using the --pattern option. Collecting the dependency
	info happens after filtering. Therefore, if Test A is filtered out,
	Test B will run unconditionally, and if Test B is filtered out,
	it simply won't run.

> This works: `git-annex test -p '/concurrent get of dup key regression/ || /Init Tests/'`
> 
> Ok, I was able to work around this by having git-annex test add the latter
> pattern automatically. [[done]] --[[Joey]]
revert windows-specific locking changes that broke tests This reverts windows-specific parts of 5a98f2d50913682c4ebe0e0c4ce695c450a96091 There were no code paths in common between windows and unix, so this will return Windows to the old behavior. The problem that the commit talks about has to do with multiple different locations where git-annex can store annex object files, but that is not too relevant to Windows anyway, because on windows the filesystem is always treated as criplled and/or symlinks are not supported, so it will only use one object location. It would need to be using a repo populated in another OS to have the other object location in use probably. Then a drop and get could possibly lead to a dangling lock file. And, I was not able to actually reproduce that situation happening before making that commit, even when I forced a race. So making these changes on windows was just begging trouble.. I suspect that the change that caused the reversion is in Annex/Content/Presence.hs. It checks if the content file exists, and then called modifyContentDirWhenExists, which seems like it would not fail, but if something deleted the content file at that point, that call would fail. Which would result in an exception being thrown, which should not normally happen from a call to inAnnexSafe. That was a windows-specific change; the unix side did not have an equivilant change. Sponsored-by: Dartmouth College's Datalad project 2022-05-23 17:04:39 +00:00			The changes to make `git-annex test` concurrent have
			broken using eg `git-annex test -p 'concurrent get of dup key regression'`

fix git-annex test -p test: When limiting tests to run with -p, work around tasty limitation by automatically including dependent tests. This fixes a reversion because it didn't used to use dependencies and forced tasty to run the init tests first. That changed when parallelizing the test suite. It will sometimes do a little more work than strictly required, because it adds init tests deps when limited to eg quickcheck tests, which don't depend on them. But this only adds a few seconds work. Sponsored-by: Dartmouth College's Datalad project 2022-05-23 18:12:24 +00:00			`It looks like the repo setup test is not being run, even though it's`
revert windows-specific locking changes that broke tests This reverts windows-specific parts of 5a98f2d50913682c4ebe0e0c4ce695c450a96091 There were no code paths in common between windows and unix, so this will return Windows to the old behavior. The problem that the commit talks about has to do with multiple different locations where git-annex can store annex object files, but that is not too relevant to Windows anyway, because on windows the filesystem is always treated as criplled and/or symlinks are not supported, so it will only use one object location. It would need to be using a repo populated in another OS to have the other object location in use probably. Then a drop and get could possibly lead to a dangling lock file. And, I was not able to actually reproduce that situation happening before making that commit, even when I forced a race. So making these changes on windows was just begging trouble.. I suspect that the change that caused the reversion is in Annex/Content/Presence.hs. It checks if the content file exists, and then called modifyContentDirWhenExists, which seems like it would not fail, but if something deleted the content file at that point, that call would fail. Which would result in an exception being thrown, which should not normally happen from a call to inAnnexSafe. That was a windows-specific change; the unix side did not have an equivilant change. Sponsored-by: Dartmouth College's Datalad project 2022-05-23 17:04:39 +00:00			`supposed to be a dependency of the test it was limited to.`
			`--[[Joey]]`
fix git-annex test -p test: When limiting tests to run with -p, work around tasty limitation by automatically including dependent tests. This fixes a reversion because it didn't used to use dependencies and forced tasty to run the init tests first. That changed when parallelizing the test suite. It will sometimes do a little more work than strictly required, because it adds init tests deps when limited to eg quickcheck tests, which don't depend on them. But this only adds a few seconds work. Sponsored-by: Dartmouth College's Datalad project 2022-05-23 18:12:24 +00:00
			`> Oh, that seems to be a limitation of tasty. From its docs:`

			`If Test B depends on Test A, remember that either of them may be`
			`filtered out using the --pattern option. Collecting the dependency`
			`info happens after filtering. Therefore, if Test A is filtered out,`
			`Test B will run unconditionally, and if Test B is filtered out,`
			`it simply won't run.`

			> This works: `git-annex test -p '/concurrent get of dup key regression/ \|\| /Init Tests/'`
			`>`
			`> Ok, I was able to work around this by having git-annex test add the latter`
			`> pattern automatically. [[done]] --[[Joey]]`