Various functions were passing through the API response as a whole, but
effectively only needed it for a status message (if any). Reduce what's
returned to only the message.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- also check errors that were previously not handled
- use the fakeCLI's buffer instead of creating one manually
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Be more explicit on not returning a response if there was an error;
change some non-exported functions to return a pointer, and return
nil instead.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Now, if running in "detached" mode, we early exit at L222.
Similarly, if `attachContainer` errors out, it returns an error that
gets handled on L190.
As such, `errCh` can never be nil on L231. Remove the nil check.
Signed-off-by: Laura Brehm <laurabrehm@hey.com>
Since everything else after the `apiClient.ContainerStart` block is
under an `if attach` conditional, we can move the "detached" early exit
up.
Signed-off-by: Laura Brehm <laurabrehm@hey.com>
During a `docker run`, the CLI has some different behavior/output
depending on whether the run is "detached" or not.
In some cases, the CLI is checking whether either `stdin`, `stdout` or
`stderr` are attached, but in other cases we're only checking `stdout`
and `stderr`, which leads to some inconsistencies:
```
$ docker run -a stdout --rm --name test alpine top
[docker kill test]
exit status 137
$ docker run -a stderr --rm --name test alpine top
[docker kill test]
exit status 137
$ docker run -a stdin --rm --name test alpine top
56820d94a89b96889478241ae68920323332c6d4cf9b51ba9340cba01e9e0565
[docker kill test]
[no exit code]
```
Since we're not checking for whether `stdin` is attached when deciding
whether to early exit without receiving on `statusChan`, the `docker run
-a stdin` is falling into the "detached mode" logic, which simply prints
the container ID and doesn't print/return the exit code.
This patch makes the "attached" checks consistent.
Signed-off-by: Laura Brehm <laurabrehm@hey.com>
The Class field was added because Docker Hub registry required a special
scope to be set for pulling plugins;
HTTP/1.1 401 Unauthorized
...
Www-Authenticate: Bearer realm="https://auth.docker.io/token",service="registry.docker.io",scope="repository(plugin):vieux/sshfs:pull",error="insufficient_scope"
This is no longer a requirement, and the field is no longer set.
updates 0ba820ed0b
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Fix a case where one inaccessible plugin search path stops the whole
search and prevents latter paths from being scanned.
Remove a preliminary `Stat` call that verifies whether path is an actual
directory and is accessible.
It's unneeded and doesn't actually check whether the directory can be
listed or not.
`os.ReadDir` will fail in such case anyway, so just attempt to do that
and ignore any encountered error, instead of erroring out the whole
plugin candidate listing.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
This patch fixes the context cancellation
behaviour for the `runContainer` function,
specifically the `createContainer` function
introduced in this commit https://github.com/docker/cli/commit/991b1303daec833d662ec54002d1b34c8805afab.
It delays stripping the `cancel` from the context
passed into the `runContainer` function so that
the `createContainer` function can be cancelled
gracefully by a SIGTERM/SIGINT.
This is especially true when the requested image
does not exist and `docker run` needs to `pull`
the image before creating the container.
Although this patch does gracefully cancel
the `runContainer` function it does not address
the root cause. Some functions in the call path
are not context aware, such as `pullImage`.
Future work would still be necessary to ensure
a consistent behaviour in the CLI.
Signed-off-by: Alano Terblanche <18033717+Benehiko@users.noreply.github.com>
There's no need for `case=[xxx]` in table tests, Go does a good job of
formatting the test output and we're just adding the same information
for every test output line.
Previously:
```console
$ go test -count=1 -v -run=TestPromptForConfirmation ./cli/command
=== RUN TestPromptForConfirmation
=== RUN TestPromptForConfirmation/case=SIGINT
=== RUN TestPromptForConfirmation/case=no
=== RUN TestPromptForConfirmation/case=yes
=== RUN TestPromptForConfirmation/case=any
=== RUN TestPromptForConfirmation/case=with_space
=== RUN TestPromptForConfirmation/case=reader_closed
--- PASS: TestPromptForConfirmation (0.00s)
--- PASS: TestPromptForConfirmation/case=SIGINT (0.00s)
--- PASS: TestPromptForConfirmation/case=no (0.00s)
--- PASS: TestPromptForConfirmation/case=yes (0.00s)
--- PASS: TestPromptForConfirmation/case=any (0.00s)
--- PASS: TestPromptForConfirmation/case=with_space (0.00s)
--- PASS: TestPromptForConfirmation/case=reader_closed (0.00s)
PASS
ok github.com/docker/cli/cli/command 0.013s
```
After:
```console
go test -count=1 -v -run=TestPromptForConfirmation ./cli/command
=== RUN TestPromptForConfirmation
=== RUN TestPromptForConfirmation/SIGINT
=== RUN TestPromptForConfirmation/no
=== RUN TestPromptForConfirmation/yes
=== RUN TestPromptForConfirmation/any
=== RUN TestPromptForConfirmation/with_space
=== RUN TestPromptForConfirmation/reader_closed
--- PASS: TestPromptForConfirmation (0.00s)
--- PASS: TestPromptForConfirmation/SIGINT (0.00s)
--- PASS: TestPromptForConfirmation/no (0.00s)
--- PASS: TestPromptForConfirmation/yes (0.00s)
--- PASS: TestPromptForConfirmation/any (0.00s)
--- PASS: TestPromptForConfirmation/with_space (0.00s)
--- PASS: TestPromptForConfirmation/reader_closed (0.00s)
PASS
ok github.com/docker/cli/cli/command 0.009s
```
Signed-off-by: Laura Brehm <laurabrehm@hey.com>
The commit guidelines are too vague and offer little guidance on
acceptable commit styles. This patch expands on what is acceptable
with some examples of what a commit is supposed to look like.
Signed-off-by: Alano Terblanche <18033717+Benehiko@users.noreply.github.com>
Co-authored-by: Christopher Petito <47751006+krissetto@users.noreply.github.com>
If we have an error type that we're checking a substring against, we
should really be checking using ErrorContains to indicate the right
semantics to assert.
Mostly done using these transforms:
find . -type f -name "*_test.go" | \
xargs gofmt -w -r 'assert.Assert(t, is.ErrorContains(e, s)) -> assert.ErrorContains(t, e, s)'
find . -type f -name "*_test.go" | \
xargs gofmt -w -r 'assert.Assert(t, is.Contains(err.Error(), s)) -> assert.ErrorContains(t, err, s)'
find . -type f -name "*_test.go" | \
xargs gofmt -w -r 'assert.Check(t, is.Contains(err.Error(), s)) -> assert.Check(t, is.ErrorContains(err, s))'
As well as some small fixups to helpers that were doing
strings.Contains explicitly.
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
Sebastiaan van Stijn
Sebastiaan van StijnandGitHub
Albin Kerouanton
Laura Brehm
Rob Murray
David Karlsson
Paweł Gronowski
Alano Terblanche
Aleksa Sarai