Random unit test failure in TestRepository_GetAnnotatedTag

[zeripath]

Gitea Version

1.15.x/1.16.x/main

Git Version

On CI

Operating System

Linux

How are you running Gitea?

In the CI

Database

SQLite

Can you reproduce the bug on the Gitea demo site?

Yes

Log Gist

No response

Description

TestRepository_GetAnnotatedTag (0.24s)
    repo_tag_test.go:90: 
        	Error Trace:	repo_tag_test.go:90
        	Error:      	Received unexpected error:
        	            	exit status 128 - fatal: destination path 'tests/repos/repo1_TestRepository_GetTag' already exists and is not an empty directory.

This test and the rest of the tests in this file should be changed to clone into random temporary directories:

gitea/modules/git/repo_tag_test.go

Lines 86 to 91 in 726715f

	func TestRepository_GetAnnotatedTag(t *testing.T) {
	bareRepo1Path := filepath.Join(testReposDir, "repo1_bare")
	clonedPath, err := cloneRepo(bareRepo1Path, testReposDir, "repo1_TestRepository_GetTag")
	assert.NoError(t, err)
	defer util.RemoveAll(clonedPath)

Screenshots

No response

[wxiaoguang]

Some more related issues (maybe not related, just FYI):

• CI fails with strange errors (randomly) #17719
• CI unrelated failures #18077

Some comments before:

• wxiaoguang: I guess the problem is possibly caused by concurrent running tests, or async queue tasks, some of them may conflict.
• singuliere: After adding -cpu=1 to unit-test-coverage I did not exprience any random failure when running drone exec --pipeline testing-amd64 .drone.yml locally on my laptop.

[zeripath]

Thanks for the link to the summary issue.

Whilst the summary issues can be helpful - the solutions and causes for them are going to be disparate and so unless some work is done to investigate each cause in turn it's not going to be solved.

I've opened this issue as I've just done that work for this particular failure.

In this case although I'm not completely aware of why the "temp" path being already extant causes the problem or how it could already be extant - it's clear that the solution would be to use a real individual temporary path for each one in turn.

A pr doing that would be simple and if no one does it before me I will put one in later today.

[zeripath]

Case 6 in #17719 should be fixed by the attached PR.

[zeripath]

Case 3 in #17719 is slightly related to this PR - however, I think it's particularly interesting as it implies that the testcase repositories aren't available. This is weird and probably indicates some error higher up whereby the test repos haven't been cloned properly or a testcase is actually deleting them.

It may be that this PR fixes this case too.

[wxiaoguang]

Cool, then we can close #17719 (it's a little old) by the new PR, then if we meet new errors, we record them in a new issue.

[zeripath]

Dunno maybe we should keep it open - there are more than a few cases in there that haven't been properly addressed, but we may want to open individual issues for each as we investigate them.