GNU/Linux: Second test run always fails.

Development
1

Hello syncthing fellows!

Please, can anybody shed some light on how to test the syncthing binary after building it on a GNU/Linux machine?

I cloned the syncthing repo, checked out v1.15.0 and (as the docs say) used the command “go run build.go test”. The tests succeeded. After some time I tried to run the tests again. But GO simply printed previously cached test results. So I tried to run “go clean -testcache” and then started the tests again. Indeed, GO started to run the tests from scratch.

The problem is that this second run failed. In fact all subsequent test runs fail consistently.

I tried to delete the whole syncthing repo as well as ~/.cache/go-build and ~/go and start the whole thing all over again. I even tried with v1.14.0 tag. But nothing helped. No matter what I try, the first test run is successful and the next one always fails with:

— FAIL: TestRequestRemoteRenameChanged (2.61s) requests_test.go:763: Got more than one index update for b

What am I doing wrong? Where should I start to get more familiar with the syncthing build and test setup?

The motivation for re-running the tests is to build more syncthing binaries - with different build flags, e.g. ‘-no-upgrade’. It is not very practical to delete the whole syncthing repo after each build run.

I am using Debian 10 (Buster) and my GO version is go1.14 linux/amd64. This is my first encounter with syncthing and I am new to GO too. So please go easy on me.

Any help would be appreciated.

Tom

2

So, to begin with the caching is good and reasonable – if the code and environment is identical Go doesn’t re-run the test, because there’s nothing that should cause a different result. So I wouldn’t worry about the caching. Secondly Go 1.14 is below requirements at this point, you want Go 1.15 or ideally Go 1.16.

That said, this doesn’t reproduce for me. I grabbed my closest Linux box with Go 1.16 and run while go run build.go test ; do go clean -testcache ; done. It loops for as long as I let it without failure.

Fourthly though, I seem to remember the specific test you mention being somewhat flaky. If you can narrow down what causes it to fail in your setup that’d be helpful.

1 Like