As pointed out in #1459, docker cli fails to detect that the input is a tarball,
in case it is generated by `git archive --format=tgz`.
This happens because `git archive` adds some metadata to the initial tar header,
and so it is more than 1 block (of 512 bytes) long, while we only provide 1 block
to archive/tar.Next() and it fails.
To fix, give it 2 blocks :)
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
This adds validation to `docker container run` / `docker container create`;
Validation of labels provided through flags was removed in 31dc5c0a9a,
after the validation was changed to fix labels without values, and to prevent
labels from being expanded with environment variables in 2b17f4c8a8
However, now empty label names from _files_ (`--label-file`) followed different
validation rules than labels passed through `--label`.
This patch adds back minimal validation for labels passed through the command-line
Before this patch:
```bash
docker container create \
--name label \
--label==with-leading-equal-sign \
--label=without-value \
--label=somelabel=somevalue \
--label " = " \
--label=with-quotes-in-value='{"foo"}' \
--label='with"quotes"in-key=test' \
busybox
docker container inspect --format '{{json .Config.Labels}}' label
```
```json
{
"": "with-leading-equal-sign",
" ": " ",
"somelabel": "somevalue",
"with\"quotes\"in-key": "test",
"with-quotes-in-value": "{\"foo\"}",
"without-value": ""
}
```
After this patch:
```bash
docker container create \
--name label \
--label==with-leading-equal-sign \
--label=without-value \
--label=somelabel=somevalue \
--label " = " \
--label=with-quotes-in-value='{"foo"}' \
--label='with"quotes"in-key=test' \
busybox
invalid argument "=with-leading-equal-sign" for "-l, --label" flag: invalid label format: "=with-leading-equal-sign"
```
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>
Tibor Vass
Lifubang
Kir Kolyshkin
leonGravel
Tõnis Tiigi
Harald Albers
Sebastiaan van Stijn
Tibor Vass
Simon Ferquel
Sunny
Stefan Scherer
Silvin Lubecki
Sebastiaan van Stijn
Vincent Demeester
Stephane Jeandeaux