-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
attach: Use ContainerWait instead of Inspect #696
Conversation
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.
Change looks good, but there are test and lint failure
Would you mind writing a TestAttach
in e2e/container/attach_test.go
?
Sure, will give it a go |
@@ -66,6 +66,9 @@ func runAttach(dockerCli command.Cli, opts *attachOptions) error { | |||
ctx := context.Background() | |||
client := dockerCli.Client() | |||
|
|||
// request channel to wait for client | |||
resultC, errC := client.ContainerWait(ctx, opts.container, "") |
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.
Oh, actually I think this should come after inspectContainerAndCheckState()
which is a sanity check on the state of the container.
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 wanted to avoid a race when by the time we return from inspectContainerAndCheckState()
the container had exited, but I don't mind moving it afterwards.
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.
good point, maybe it is more correct before the inspect. The error from ContainerWait()
wouldn't be reported until later, so the user would still see the helpful error message.
I think this is correct, ignore my comment.
864ba8b
to
992c9ee
Compare
Codecov Report
@@ Coverage Diff @@
## master #696 +/- ##
=========================================
- Coverage 51.28% 50.6% -0.68%
=========================================
Files 216 216
Lines 17743 17728 -15
=========================================
- Hits 9099 8972 -127
- Misses 8175 8304 +129
+ Partials 469 452 -17 |
I'm not sure what to do about the gocyclo complain. I don't want to make a function just because of it. So if we don't want to raise the limit, I would need to think of a way of refactoring the would function. Regarding the test failure, it is very strange, it looks like we do get the output, but don't notice that the process is dead? I haven't been able to reproduce it locally. |
cli/command/container/attach.go
Outdated
@@ -140,7 +143,18 @@ func runAttach(dockerCli command.Cli, opts *attachOptions) error { | |||
if errAttach != nil { | |||
return errAttach | |||
} | |||
return getExitStatus(ctx, dockerCli.Client(), opts.container) | |||
|
|||
// get status code |
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.
This seems like a perfect place to create a new function. A function is always better than an inline comment as it provides a scope for the documentation.
I think the unit test you removed could be preserved and used to test the function, with a few small changes to the test setup. The 3 cases in the table test are still relevant.
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.
It feels weird given that it's really just a select, the comment could be removed without affecting readability, but I'll try that.
e2e/container/attach_test.go
Outdated
cmd := icmd.Command("docker", "wait", cName) | ||
res := icmd.StartCmd(cmd) | ||
icmd.RunCommand("docker", "attach", cName).Assert(t, icmd.Expected{ExitCode: 21}) | ||
icmd.WaitOnCmd(8, res).Assert(t, icmd.Expected{ExitCode: 0, Out: "21"}) |
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.
This is only waiting 8ms, I'm not sure if that's related to the failure.
I'll see if I can get this working
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.
This test fails for me locally as well so I'll prepare a patch to get it working.
I think the docker wait
command is unnecessary, all we need is a poll.WaitOn()
for the container to be started.
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.
Didn't realize it was in ms
😅
Thanks poll.WaitOn()
seems to be what I was looking for. I'll try updating the code tonight.
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 pushed a commit, it seems to be working now. I didn't use the WaitOn for container start. I'm not sure if this test can flake, maybe runBackgroundContainsWithExitCode()
could use a WaitOn if we see it flake.
I pushed a commit to this branch which I think will fix the e2e suite. Edit: build didn't trigger on jenkins for some reason, so I forced a run from jenkins ui Edit: it's green! |
361354c
to
e84bf6c
Compare
Signed-off-by: Kenfe-Mickael Laventure <mickael.laventure@gmail.com>
Signed-off-by: Daniel Nephin <dnephin@docker.com>
e84bf6c
to
bace33d
Compare
All green 💚 |
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
What caused this change? Was there a problem in all previous versions or did the API change? The linked issue seems like a regression. |
From my understanding of the code, the race was always here, is just that a bit more of the post processing has been moved to the event handler now and increased the latency. |
LGTM |
Looks like we have 2 LGTM's; merging |
FYI this PR don't play nice with latest code from
Reverting the changes in this PR and stuff goes green. |
That test seems to have a 2s timeout for |
Seems to be an issue with the test, Opened moby/moby#36363 |
Signed-off-by: Kenfe-Mickael Laventure mickael.laventure@gmail.com
--
Addresses moby/moby#35497
- What I did
Use
ContainerWait()
instead ofInspect
to retrieve the final exit code in atach- How I did it
Changed the code ;-)
- How to verify it
- Description for the changelog
Ensure attach exit code matches container's
- A picture of a cute animal (not mandatory but encouraged)
🐶