If a file contains trailing whitespace, the YAML generator uses a
compact format, which is hard to read.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The Dockerfile `ENV` instruction allows values to be set using either `ENV name=value`
or `ENV name value`. The latter (`ENV name value`) form can be ambiguous, for example,
the following defines a single env-variable (`ONE`) with value `"TWO= THREE=world"`,
but may have intended to be setting three env-vars:
ENV ONE TWO= THREE=world
This format also does not allow setting multiple environment-variables in a single
`ENV` line in the Dockerfile.
Use of the `ENV name value` syntax is discouraged, and may be removed in a future
release. Users are encouraged to update their Dockerfiles to use the `ENV name=value`
syntax, for example:
ENV ONE="" TWO="" THREE="world"
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The `ENV key value` form can be ambiguous, for example, the following defines
a single env-variable (`ONE`) with value `"TWO= THREE=world"`:
ENV ONE TWO= THREE=world
While we cannot deprecate/remove that syntax (as it would break existing
Dockerfiles), we should reduce exposure of the format in our examples.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
When creating and updating services, we need to avoid unneeded service churn.
The interaction of separate lists to "add" and "drop" capabilities, a special
("ALL") capability, as well as a "relaxed" format for accepted capabilities
(case-insensitive, `CAP_` prefix optional) make this rather involved.
This patch updates how we handle `--cap-add` / `--cap-drop` when _creating_ as
well as _updating_, with the following rules/assumptions applied:
- both existing (service spec) and new (values passed through flags or in
the compose-file) are normalized and de-duplicated before use.
- the special "ALL" capability is equivalent to "all capabilities" and taken
into account when normalizing capabilities. Combining "ALL" capabilities
and other capabilities is therefore equivalent to just specifying "ALL".
- adding capabilities takes precedence over dropping, which means that if
a capability is both set to be "dropped" and to be "added", it is removed
from the list to "drop".
- the final lists should be sorted and normalized to reduce service churn
- no validation of capabilities is handled by the client. Validation is
delegated to the daemon/server.
When deploying a service using a docker-compose file, the docker-compose file
is *mostly* handled as being "declarative". However, many of the issues outlined
above also apply to compose-files, so similar handling is applied to compose
files as well to prevent service churn.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The docker CLI up until v1.7.0 used the `~/.dockercfg` file to store credentials
after authenticating to a registry (`docker login`). Docker v1.7.0 replaced this
file with a new CLI configuration file, located in `~/.docker/config.json`. When
implementing the new configuration file, the old file (and file-format) was kept
as a fall-back, to assist existing users with migrating to the new file.
Given that the old file format encourages insecure storage of credentials
(credentials are stored unencrypted), and that no version of the CLI since
Docker v1.7.0 has created this file, the file is marked deprecated, and support
for this file will be removed in a future release.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The output format was changed to combine tag and name in a single
column, but this change was never reflected in the docs.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This reflects a Moby change to add documentation around
disabling a new feature -- to use pgzip to decompress
layers, rather than the built-in go gzip.
Signed-off-by: Sargun Dhillon <sargun@sargun.me>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This creates a new section of environment variables in the CLI docs
which documents environment variables that can both be used on dockerd
and on docker cli.
In addition, it moves some of the environment variable documentation
from the docker cli documentation to the dockerd documentation, as
these environment variables are dockerd-specific.
Signed-off-by: Sargun Dhillon <sargun@sargun.me>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The Engine API docs are not available in this GitHub repository,
so linking to the docs.docker.com website instead.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- replace the "none" code-hint with "console"
- some changes in the "experimental" instructions
- reformat some notes
- reformat / re-indent JSON output to use 2 spaces (for consistency)
- split JSON outputs to separate code-block so that it can be highlighted
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This adds the currently selected "docker context" to the output
of "docker version", which allows users to see which context
is selected to produce the version output, and can be used (for
example), to set the prompt to the currently selected context:
(in `~/.bashrc`):
```bash
function docker_context_prompt() {
PS1="context: $(docker version --format='{{.Client.Context}}')> "
}
PROMPT_COMMAND=docker_context_prompt
```
After reloading the `~/.bashrc`, the prompt now shows the currently selected
`docker context`:
```bash
$ source ~/.bashrc
context: default> docker context create --docker host=unix:///var/run/docker.sock my-context
my-context
Successfully created context "my-context"
context: default> docker context use my-context
my-context
Current context is now "my-context"
context: my-context> docker context use default
default
Current context is now "default"
context: default>
```
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Using `/var/run/docker.sock` as docker host is invalid, and causes
an error, so adding `unix://` to it.
In addition, we document the name of the context to go after the
options, so change the order in the examples.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
1. Fix dead URL to [Dockerfile best practices](https://docs.docker.com/develop/develop-images/dockerfile_best-practices/#leverage-build-cache).
2. Add missing information about cache invalidation by `COPY`. It works in the same way as in the case of `ADD`. Informing only about the `ADD`s behavior is misleading as one can infer that these two directives differ in this regard.
3. Add missing info on RUN cache invalidation by COPY
Signed-off-by: Maciej Kalisz <maciej.d.kalisz@gmail.com>
This link was broken when generating the documentation (due to
a bug in Jekyll not converting wrapped internal links)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
* Added two new modes accepted by the `--mode` flag
* `replicated-job` creates a replicated job
* `global-job` creates a global job.
* When using `replicated-job` mode, the `replicas` flag sets the
`TotalCompletions` parameter of the job. This is the total number of
tasks that will run
* Added a new flag, `max-concurrent`, for use with `replicated-job`
mode. This flag sets the `MaxConcurrent` parameter of the job, which
is the maximum number of replicas the job will run simultaneously.
* When using `replicated-job` or `global-job` mode, using any of the
update parameter flags will result in an error, as jobs cannot be
updated in the traditional sense.
* Updated the `docker service ls` UI to include the completion status
(completed vs total tasks) if the service is a job.
* Updated the progress bars UI for service creation and update to
support jobs. For jobs, there is displayed a bar covering the overall
progress of the job (the number of tasks completed over the total
number of tasks to complete).
* Added documentation explaining the use of the new flags, and of jobs
in general.
Signed-off-by: Drew Erny <derny@mirantis.com>
Service create expects the name to be passed using the
`--name` flag, not as a positional parameter
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Currently the documentation uses a special case for this command,
so adding a description to the YAML in order to remove that
special case.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Colon may not be something non-native English readers
know about, so explain the symbol in the running text.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- add code-fences with code-hints so that the right hightlighting is applied
- replace `*` for `-` in bullet-lists for consistency with other parts of the
documentation.
- reduced number of "notes", either by combining some, or by changing some
to regular text.
- removed "line numbers" from some examples, because there's only four lines,
which should not need really need line numbers.
- reformat some notes to our new format
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- add code-fences with code-hints so that the right
hightlighting is applied
- reduced number of "notes", either by combining some,
or by changing some to regular text.
- use tables for some option lists
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- fix various broken links
- fix incorrect anchors
- updated links for content that moved, so that no
redirect to the new location is needed.
- touched-up Markdown;
- re-format some JSON output
- add blank line betweeen command and command output
- format "note" blocks
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The `docker network prune` command removes unused custom networks,
but built-in networks won't be removed. This patch updates the
message to mention that it's only removing custom networks.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The deprecation policy was written when we had monthly releases
(edge+stable), and stable releases were released every 3 months.
The release cadence has changed to be longer than 3 months for
stable releases, so adjusting the policy accordingly.
Note that the policy continues to be "at least x releases", so
even though we _can_ remove a feature after one release, it does
not mean we _must_ remove it: announcing deprecations early helps
users migrate away from features we do not intent to support in
future.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This section was included on a page on docs.docker.com, but not linked
in the navigation. Putting the section on the deprecated features page
to be sure they can be found together.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
these markdown files are not consumed directly in the docs,
but only their content is included through the YAML does,
so there's no need to have these comments in them
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Unlike GitHub's web-UI, the "rouge" hightlighter used in our
online documentation is case-sensitive. As a result, code-blocks
having the Dockerfile (uppercase) code-hint were not highlighted.
This changes those to use lowercase, which is supported by both.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
If the markdown contains trailing spaces, or has tabs included,
the YAML generator uses a compact format for the text (using `\n`
and `\t`, instead of plain newlines).
The compact format makes it difficult to review changes in the
yaml docs when vendoring in the documentation repository.
This patch:
- removes trailing whitespace
- replaces tabs for spaces
- fixes some minor formatting and markdown issues
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The script was written to only take subcommands at the first and second level
into account, but failed to find the Markdown files for extended descriptions of
subcommands at the third level, such as `docker trust key generate`, and
`docker trust key load`:
WARN: /go/src/github.com/docker/cli/docs/reference/commandline/key_generate.md does not exist, skipping
WARN: /go/src/github.com/docker/cli/docs/reference/commandline/key_load.md does not exist, skipping
WARN: /go/src/github.com/docker/cli/docs/reference/commandline/signer_add.md does not exist, skipping
WARN: /go/src/github.com/docker/cli/docs/reference/commandline/signer_remove.md does not exist, skipping
This patch updates the script to accomodate subcommands that are more deeply
nested. While at it, some minor cleaning and linting issues were also addressed.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
These files were intended to document the `swarm join-token` and
`swarm unlock-key` subcommands, but were incorrectly using an underscore
instead of a hyphen (`-`). As a result, the examples were not picked up
by the yamldocs generator.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The `docker search --automated` and `docker search --stars` options were
deprecated in release v1.12.0, and scheduled for removal in v17.09.
This patch removes the deprecated flags, in favor of their equivalent
`--filter` options (`docker search --filter=is-automated=<true|false>` and
`docker search --filter=stars=...`).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Sebastiaan van Stijn
Tibor Vass
Albin Kerouanton
Sebastiaan van Stijn
horpto
eyherabh
Tonis Tiigi
Akihiro Suda
Brian Wieder
Silvin Lubecki
dito
Saswat Bhattacharya
Sargun Dhillon
Justin Cormack
Simon Heimberg
devisions
Silvin Lubecki
Maciej Kalisz
Drew Erny
Dominik Braun
Hector S