-
Notifications
You must be signed in to change notification settings - Fork 18.9k
hack/test/unit: run libnetwork tests sequentially
#42594
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
ed38b59 to
d2aaae8
Compare
|
@thaJeztah @fredericdalleau (and anyone else) thoughts on this? Please also see #42458 (comment) Most probably refs and maybe fixes #42553 |
|
Ah, heh. Nice find. Yes, unit tests that are not-so-unit 😞 |
|
CI failure (so far): #42459 |
|
Ah, $ go help testflag
...
-parallel n
Allow parallel execution of test functions that call t.Parallel.
The value of this flag is the maximum number of tests to run
simultaneously; by default, it is set to the value of GOMAXPROCS.
Note that -parallel only applies within a single test binary.
The 'go test' command may run tests for different packages
in parallel as well, according to the setting of the -p flag
(see 'go help build').
...
$ go help build
...
-p n
the number of programs, such as build commands or
test binaries, that can be run in parallel.
The default is the number of CPUs available.
...I don't love it (and wish we could set it just for |
|
We can absolutely filter libnetwork and run it separately |
d2aaae8 to
3c3e055
Compare
-p=1 by defaultlibnetwork tests sequentially
3c3e055 to
49bcb66
Compare
|
I added a Go test runner, which runs |
d6165dd to
147df55
Compare
|
Still did not get any feedback, moving this out of draft |
147df55 to
d9eeff5
Compare
cpuguy83
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think the added complexity here is worth it.
If we just need to ensure libnetwork tests are exclusive, we can do that in bash.
d9eeff5 to
a7e0efe
Compare
libnetwork tests sequentiallylibnetwork tests sequentially
|
A few failures that seem unrelated: |
|
Oh; forgot to leave a comment about that; I think we also will have to fix the Windows counterparts of this. i.e.; Lines 315 to 325 in 0b39cc2
and Lines 772 to 776 in 0b39cc2
|
|
🤔 although; if it's only the iptables issue that's a problem, I guess that's not needed for Windows 😂 |
494c9d7 to
58e9b93
Compare
I would think the same in this case. Are the tests in question known to be flaky on Windows in particular? |
58e9b93 to
6e8466b
Compare
|
Looks like we actually need to apply this flag to a smaller set of packages, I guess only the ones depending on |
Wondering; Can we re-enable parallel as part of those tests itself? |
I don't think we can do that. We could try to do some trickery in |
|
Yeah, so I was wondering |
|
Oh, nevermind, that is not caused by this change - it turns out that those tests are never actually run on CI, e.g. on latest master arm64 build (https://ci-next.docker.com/public/blue/organizations/jenkins/moby/detail/master/1006/pipeline/363):
|
|
cc @samuelkarp |
thaJeztah
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
perhaps we should create a tracking issue for the tests that are currently skipped because we don't have -parallel enabled
Run all tests within `libnetwork` namespace with `-p=1` in a separate `gotestsum` invocation. Signed-off-by: Roman Volosatovs <roman.volosatovs@docker.com>
6e8466b to
3af2217
Compare
thaJeztah
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
samuelkarp
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks!
- What I did
Run
libnetworktests sequentially. See #42458 (comment) for explanation.Closes #42458 maybe more
Note, that many tests in
libnetwork/...already depend on the assumption that they are run sequentially and do not "easily" support things like-rundue to that fact. E.g. this test is a prime example of such behavior:moby/libnetwork/iptables/iptables_test.go
Lines 1 to 327 in 45b45ad
I, personally, don't think that
-p=1is the "correct" solution here. Although, to do this "right" I think we'd have to rewrite a large portion oflibnetworktests and I do not think that is worth it at this point.- How I did it
Run
gotestsumat most twice and pass-p=1when running unit tests in/libnetworknamespace- How to verify it
e.g.
TESTDIRS='github.com/docker/docker/libnetwork/iptables github.com/docker/docker/libnetwork/drivers/bridge' make test-unitshould pass (and sometimes fail without this change)- Description for the changelog
- A picture of a cute animal (not mandatory but encouraged)