Conversation
|
Windows failure is a test that will be removed; #35844
|
internal/testutil/helpers.go
Outdated
There was a problem hiding this comment.
'\x00' is a rune which results in a byte having all bits set to zero. 0 is an integer constant having all bits set to zero. These two have the same effect when assigned to a byte (see https://play.golang.org/p/IUboS5HCYkI). Now sure what do you mean by NULL, but if there would be NULL in Go as it is in C, it will also be equal to 0 and \x00 (although, if I remember it correctly, this is not guaranteed by the C language specification, but is true in practice for every implementation known). Now, nil might be equivalent, too, but due to strict[er than C] type checking it can not be assigned to a byte.
The code before and after this patch is equivalent in what it's doing, but somehow Go fails to optimize the binary code for the old version, and optimizes the new one pretty good, as described in patch commit message.
There was a problem hiding this comment.
Oh, thanks! I for some reason thought NULL would be different than 0; shows what I know 😊
|
Error is because the daemon failed to start:
|
1. The functionality of this test is superceded by `TestAPIIpcModeShareableAndContainer` (see integration-cli/docker_api_ipcmode_test.go). 2. This test won't work with --default-ipc-mode private. Signed-off-by: Kir Kolyshkin <[email protected]>
`TestCleanupMountsAfterDaemonAndContainerKill` was supposedly written when the container mounts were visible from the host. Currently they all live in their own mount namespace and the only visible mount is the tmpfs one for shareable /dev/shm inside the container (i.e. /var/lib/docker/containers/<ID>/shm), which will no longer be there in case of `--default-ipc-mode private` is used, and so the test will fail. Add a check if any container mounts are visible from the host, and skip the test if there are none, as there's nothing to check. `TestCleanupMountsAfterDaemonCrash`: fix in a similar way, keeping all the other checks it does, and skipping the "mounts gone" check if there were no mounts visible from the host. While at it, also fix the tests to use `d.Kill()` in order to not leave behind a stale `docker.pid` files. Signed-off-by: Kir Kolyshkin <[email protected]>
I got the following test failure on power:
10:00:56
10:00:56
----------------------------------------------------------------------
10:00:56 FAIL: docker_cli_build_test.go:3521:
DockerSuite.TestBuildNotVerboseFailureRemote
10:00:56
10:00:56 docker_cli_build_test.go:3536:
10:00:56 c.Fatal(fmt.Errorf("Test[%s] expected that quiet stderr and
verbose stdout are equal; quiet [%v], verbose [%v]", name,
quietResult.Stderr(), result.Combined()))
10:00:56 ... Error: Test[quiet_build_wrong_remote] expected that quiet
stderr and verbose stdout are equal; quiet [
10:00:56 unable to prepare context: unable to download remote context
http://something.invalid: Get http://something.invalid: dial tcp: lookup
something.invalid on 172.29.128.11:53: no such host
10:00:56 ], verbose [unable to prepare context: unable to download
remote context http://something.invalid: Get http://something.invalid:
dial tcp: lookup something.invalid on 8.8.8.8:53: no such host
10:00:56 ]
10:00:56
10:00:56
10:00:56
----------------------------------------------------------------------
The reason is, either more than one name server is configured, or
nameserver was reconfigured in the middle of the test run. In any case,
different nameserver IP in an error messages should not be treated
as a failure, so let's strip those out.
Signed-off-by: Kir Kolyshkin <[email protected]>
According to golang/go#5373, go recognizes (and optimizes for) the following syntax: ```go for i := range b { b[i] = 0 } ``` so let's use it. Limited testing shows ~7.5x speed increase, compared to the previously used syntax. Signed-off-by: Kir Kolyshkin <[email protected]>
Those are some test fixes I made while working on other stuff. Those are largely unrelated, so please see descriptions in individual commit messages (for the same reason, please review commits individually so you won't miss those descriptions).