When using advanced syntax for setting config and secret values, default
the target value to the source value when the user does not specify a
target.
Signed-off-by: Nick Adcock <nick.adcock@docker.com>
Allow the use of the advanced source=x syntax for config and secret values when there is no comma
Before this change the following would fail with config not found:
docker service create --name hello1 --config source=myconfig nginx:alpine
And the following would fail with secret not found:
docker service create --name hello2 --secret source=mysecret nginx:alpine
Signed-off-by: Nick Adcock <nick.adcock@docker.com>
```
opts/network_test.go:74:35: Using the variable on range scope `tc` in function literal (scopelint)
assert.NilError(t, network.Set(tc.value))
^
opts/network_test.go:102:40: Using the variable on range scope `tc` in function literal (scopelint)
assert.ErrorContains(t, network.Set(tc.value), tc.expectedError)
^
opts/opts_test.go:270:30: Using the variable on range scope `tc` in function literal (scopelint)
val, err := ValidateLabel(tc.value)
^
opts/opts_test.go:271:7: Using the variable on range scope `tc` in function literal (scopelint)
if tc.expectedErr != "" {
^
```
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
For now, just verifying that an error is returned, but not checking the
error message itself, because those are not under our control, and may
change with different Go versions.
```
=== Failed
=== FAIL: opts TestParseDockerDaemonHost (0.00s)
hosts_test.go:87: tcp tcp:a.b.c.d address expected error "Invalid bind address format: tcp:a.b.c.d" return, got "parse tcp://tcp:a.b.c.d: invalid port \":a.b.c.d\" after host" and addr
hosts_test.go:87: tcp tcp:a.b.c.d/path address expected error "Invalid bind address format: tcp:a.b.c.d/path" return, got "parse tcp://tcp:a.b.c.d/path: invalid port \":a.b.c.d\" after host" and addr
=== FAIL: opts TestParseTCP (0.00s)
hosts_test.go:129: tcp tcp:a.b.c.d address expected error Invalid bind address format: tcp:a.b.c.d return, got parse tcp://tcp:a.b.c.d: invalid port ":a.b.c.d" after host and addr
hosts_test.go:129: tcp tcp:a.b.c.d/path address expected error Invalid bind address format: tcp:a.b.c.d/path return, got parse tcp://tcp:a.b.c.d/path: invalid port ":a.b.c.d" after host and addr
```
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This allows setting the ip/ipv6 address as an option in the
advanced `--network` syntax;
```
docker run --network name=mynetwork,ip=172.20.88.22,ip6=2001:db8::8822
```
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This refactors the way networking options are parsed, and makes the
client able to pass options for multiple networks. Currently, the
daemon does not yet accept multiple networks when creating a container,
and will produce an error.
For backward-compatibility, the following global networking-related
options are associated with the first network (in case multiple
networks are set);
- `--ip`
- `--ip6`
- `--link`
- `--link-local-ip`
- `--network-alias`
Not all of these options are supported yet in the advanced notation,
but for options that are supported, setting both the per-network option
and the global option will produce a "conflicting options" error.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The commit contains cli changes to support driver options for a network in
docker run and docker network connect cli's. The driver-opt, aliases is now
supported in the form of csv as per network option in service commands in
swarm mode since docker/cli#62 . This commit extends this support to docker
run command as well.
For docker connect command `--driver-opt` is added to pass driver specific
options for the network the container is connecting to.
Signed-off-by: Abhinandan Prativadi <abhi@docker.com>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This patch fixes a bug where labels use the same behavior as `--env`, resulting
in a value to be copied from environment variables with the same name as the
label if no value is set (i.e. a simple key, no `=` sign, no value).
An earlier pull request addressed similar cases for `docker run`;
2b17f4c8a8, but this did not address the
same situation for (e.g.) `docker service create`.
Digging in history for this bug, I found that use of the `ValidateEnv`
function for labels was added in the original implementation of the labels feature in
abb5e9a077 (diff-ae476143d40e21ac0918630f7365ed3cR34)
However, the design never intended it to expand environment variables,
and use of this function was either due to either a "copy/paste" of the
equivalent `--env` flags, or a misunderstanding (the name `ValidateEnv` does
not communicate that it also expands environment variables), and the existing
`ValidateLabel` was designed for _engine_ labels (which required a value to
be set).
Following the initial implementation, other parts of the code followed
the same (incorrect) approach, therefore leading the bug to be introduced
in services as well.
This patch:
- updates the `ValidateLabel` to match the expected validation
rules (this function is no longer used since 31dc5c0a9a),
and the daemon has its own implementation)
- corrects various locations in the code where `ValidateEnv` was used instead of `ValidateLabel`.
Before this patch:
```bash
export SOME_ENV_VAR=I_AM_SOME_ENV_VAR
docker service create --label SOME_ENV_VAR --tty --name test busybox
docker service inspect --format '{{json .Spec.Labels}}' test
{"SOME_ENV_VAR":"I_AM_SOME_ENV_VAR"}
```
After this patch:
```bash
export SOME_ENV_VAR=I_AM_SOME_ENV_VAR
docker service create --label SOME_ENV_VAR --tty --name test busybox
docker container inspect --format '{{json .Config.Labels}}' test
{"SOME_ENV_VAR":""}
```
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
gofmt/goimports changed some heuristics in 1.11 and the code is now
formatted slightly differently.
No functional change, just whitespace.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
This changes the experimental --console flag to --progress following
feedback indicating avoidable confusion.
In addition to naming changes, the help output now has an additional
clarification, specifically: container output during builds are only
shown when progress output is set to plain. Not mentioning this was also
a big cause of confusion.
Signed-off-by: Tibor Vass <tibor@docker.com>
- Use `Contains` instead of `Include`
- Use `ToJSON` instead of `ToParam`
- Remove usage of `ParseFlag` as it is deprecated too
Signed-off-by: Vincent Demeester <vincent@sbr.pm>
parsing an environment file should give an error in case a zero-length
variable name (definition w/o a variable name) is encountered.
previously these lines went through unnoticed not informing the user about
a potential configuration error.
Signed-off-by: Tom Klingenberg <tklingenberg@lastflood.net>
previously docker did import environment variables if they were present
but created them if they were not when it was asked via a --env-file
cli option to import but not create them.
fix is to only import the variable into the environment if it is present.
additionally do not import variable names of zero-length (which are lines
w/ a potential variable definition w/o a variable name).
refs:
- https://github.com/docker/for-linux/issues/284
Signed-off-by: Tom Klingenberg <tklingenberg@lastflood.net>
test to show current behavior is wrong at parsing an environment file
defining an undefined variable - it must not be defined!
NOTE: this test assume the $HOME variable is always set (see POSIX, this
normally is the case, e.g. the test suite remains stable).
Signed-off-by: Tom Klingenberg <tklingenberg@lastflood.net>
`--label-file` has the exact same behavior as `--env-file`, meaning any
placeholder (i.e. a simple key, no `=` sign, no value), it will get the
value from the environment variable.
For `--label-file` it should just add an empty label.
Signed-off-by: Vincent Demeester <vincent@sbr.pm>
I noticed that we're using a homegrown package for assertions. The
functions are extremely similar to testify, but with enough slight
differences to be confusing (for example, Equal takes its arguments in a
different order). We already vendor testify, and it's used in a few
places by tests.
I also found some problems with pkg/testutil/assert. For example, the
NotNil function seems to be broken. It checks the argument against
"nil", which only works for an interface. If you pass in a nil map or
slice, the equality check will fail.
In the interest of avoiding NIH, I'm proposing replacing
pkg/testutil/assert with testify. The test code looks almost the same,
but we avoid the confusion of having two similar but slightly different
assertion packages, and having to maintain our own package instead of
using a commonly-used one.
In the process, I found a few places where the tests should halt if an
assertion fails, so I've made those cases (that I noticed) use "require"
instead of "assert", and I've vendored the "require" package from
testify alongside the already-present "assert" package.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
Nick Adcock
Silvin Lubecki
Sebastiaan van Stijn
Silvin Lubecki
Abhinandan Prativadi
Tibor Vass
Akihiro Suda
Lifubang
Kir Kolyshkin
Vincent Demeester
Vincent Demeester
Tom Klingenberg
Andrew Hsu
Sami Tabet
Daniel Nephin
Wataru Ishida
Josh Soref
Sebastiaan van Stijn
Aaron Lehmann
Evan Hazlett