-
Notifications
You must be signed in to change notification settings - Fork 2.1k
context: improvements for handling non-existing contexts and errors #3868
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
e358130 to
005b180
Compare
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## master #3868 +/- ##
==========================================
- Coverage 59.23% 59.23% -0.01%
==========================================
Files 287 287
Lines 24656 24691 +35
==========================================
+ Hits 14605 14625 +20
- Misses 9168 9183 +15
Partials 883 883 |
| func runShow(dockerCli command.Cli) error { | ||
| context := dockerCli.CurrentContext() | ||
| metadata, err := dockerCli.ContextStore().GetMetadata(context) | ||
| fmt.Fprintln(dockerCli.Out(), context) | ||
| _, err := dockerCli.ContextStore().GetMetadata(context) | ||
| if err != nil { | ||
| return err | ||
| } | ||
| fmt.Fprintln(dockerCli.Out(), metadata.Name) | ||
| return nil | ||
| } |
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.
As this is a new command, we can still change; do we think we should produce an error at all if the context wasn't found, or just "show the name of the context" (basically: this is what's configured to use, but you'll learn if it works once you use it)?
We could still opt for printing the error (on STDERR) as a warning, but make the command always return a zero exit code ("success").
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 seems like it should mimic existing behavior for other commands. e.g. for inspect:
if dockerCli.CurrentContext() == "" {
return errors.New("no context specified")
}
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.
Hm... right; so docker context inspect expects a positional argument. It looks like there's a bug in the compose-cli wrapper, as it hijacks the docker context subcommands, and it looks like the usage information is incorrect;
This is the output for compose-cli;
docker context inspect --help
Display detailed information on one or more contexts
Usage:
docker context inspect [flags]
Flags:
-f, --format string Format the output using the given Go template
-h, --help Help for inspectAnd the output for the actual docker cli;
com.docker.cli context inspect --help
Usage: docker context inspect [OPTIONS] [CONTEXT] [CONTEXT...]
Display detailed information on one or more contexts
Options:
-f, --format string Format the output using the given Go templateThere 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.
As to the docker context show; that command was added in #3567. Basically its sole purpose is to show what context is configured, so that it can be used in prompts. An earlier PR (#2500) added it to docker info for that purpose, but docker context show is more convenient.
As it (likely) will be used for prompts, the question is, should it always validate? Without validation, the value is still valid (it shows what's configured), but even if we check if the context is valid (can be found, and decoded), it may still be pointing to a host that's not reachable.
005b180 to
01fe846
Compare
| default Current DOCKER_HOST based configuration unix:///var/run/docker.sock | ||
| other description of other https://someswarmserver.example.com | ||
| unset description of unset https://someswarmserver.example.com | ||
| NAME DESCRIPTION DOCKER ENDPOINT ERROR |
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.
ERROR looks like a copy/paste mistake here
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's the title for the ERROR column that was added, but looking at this, it looks like I have more work to do. The context store itself already fails "full stop" if it encounters an error, so without some of the other changes from #3847, it looks like this doesn't work 😞
|
Hm... more bugs (or at least differences in behaviour) in compose cli; looks like it's handling contexts differently, and happily goes ahead with empty contexts 🤔 docker context ls
NAME TYPE DESCRIPTION DOCKER ENDPOINT KUBERNETES ENDPOINT ORCHESTRATOR
moby
default moby Current DOCKER_HOST based configuration unix:///var/run/docker.sock swarm
desktop-linux * moby unix:///Users/thajeztah/.docker/run/docker.sockcom.docker.cli context ls
cannot find docker endpoint in context |
|
And ... buildx does it different as well; make shell
# build dockerfile from stdin so that we don't send the build-context; source is bind-mounted in the development environment
cat ./dockerfiles/Dockerfile.dev | docker build --build-arg=GO_VERSION -t docker-cli-dev -
ERROR: use `docker --context= buildx` to switch to context
make[1]: *** [build_docker_image] Error 1
make: *** [dev] Error 2Looks to be related to context store handling / ignoring name, which then causes it to use "" as context name, instead of the default; https://github.com/docker/buildx/blob/6e9b743296d8ba029871516370909c6f809dd935/commands/util.go#L201-L225 |
Store a reference to the options in the client, so that they can be used for later use. Now that resolveContextName() is a very lightweight function we can also dynamically get its value and use it for cli.CurrentContext(). Signed-off-by: Sebastiaan van Stijn <[email protected]>
This internalizes constructing the Client(), which allows us to provide fallbacks when trying to determin the current API version. Signed-off-by: Sebastiaan van Stijn <[email protected]>
This updates `docker context ls` to: - not abort listing contexts when failing one (or more) contexts - instead, adding an ERROR column to inform the user there was an issue loading the context. Signed-off-by: Sebastiaan van Stijn <[email protected]>
if a context is set (e.g. through DOCKER_CONTEXT or the CLI config file), but
wasn't found, then a "stub" context is added, including an error message that
the context doesn't exist.
DOCKER_CONTEXT=nosuchcontext docker context ls
NAME DESCRIPTION DOCKER ENDPOINT ERROR
default Current DOCKER_HOST based configuration unix:///var/run/docker.sock
nosuchcontext * load context "nosuchcontext": context does n…
Signed-off-by: Sebastiaan van Stijn <[email protected]>
This allows the user to still see what context is _set_ in cases where it
does not exist;
docker context show
nosuchcontext
load context "nosuchcontext": context does not exist: open /root/.docker/contexts/meta/8bfef2a74c7d06add4bf4c73b0af97d9f79c76fe151ae0e18b9d7e57104c149b/meta.json: no such file or directory
The error is printed on stderr, so can be redirected:
docker context show 2> /dev/null
nosuchcontext
echo $?
1
This can help in cases where the context is used to (e.g.) set the command-prompt,
but the user removed the context. With this change, the context name can still be
shown, but commands that _require_ the context will still fail.
Signed-off-by: Sebastiaan van Stijn <[email protected]>
01fe846 to
685449f
Compare
|
Closing as all of these were merged |
Uh oh!
There was an error while loading. Please reload this page.