cli/compose/interpolation/interpolation.go:102:4: error-strings: error strings should not be capitalized or end with punctuation or a newline (revive)
"invalid interpolation format for %s: %#v. You may need to escape any $ with another $.",
^
cli/command/stack/loader/loader.go:30:30: error-strings: error strings should not be capitalized or end with punctuation or a newline (revive)
return nil, errors.Errorf("Compose file contains unsupported options:\n\n%s\n",
^
cli/command/formatter/formatter.go:76:30: error-strings: error strings should not be capitalized or end with punctuation or a newline (revive)
return tmpl, errors.Errorf("Template parsing error: %v\n", err)
^
cli/command/formatter/formatter.go:97:24: error-strings: error strings should not be capitalized or end with punctuation or a newline (revive)
return errors.Errorf("Template parsing error: %v\n", err)
^
cli/command/image/build.go:257:25: error-strings: error strings should not be capitalized or end with punctuation or a newline (revive)
return errors.Errorf("error checking context: '%s'.", err)
^
cli/command/volume/create.go:35:27: error-strings: error strings should not be capitalized or end with punctuation or a newline (revive)
return errors.Errorf("Conflicting options: either specify --name or provide positional arg, not both\n")
^
cli/command/container/create.go:160:24: error-strings: error strings should not be capitalized or end with punctuation or a newline (revive)
return errors.Errorf("failed to remove the CID file '%s': %s \n", cid.path, err)
^
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The CLI currenly calls the `/info` endpoint to get the address
of the default registry to use.
This functionality was added as part of the initial Windows implementation
of the engine. For legal reasons, Microsoft Windows (and thus Docker images
based on Windows) were not allowed to be distributed through non-Microsoft
infrastructure. As a temporary solution, a dedicated "registry-win-tp3.docker.io"
registry was created to serve Windows images.
As a result, the default registry was no longer "fixed", so a helper function
(`ElectAuthServer`) was added to allow the CLI to get the correct registry
address from the daemon. (docker/docker PR's/issues 18019, 19891, 19973)
Using separate registries was not an ideal solution, and a more permanent
solution was created by introducing "foreign image layers" in the distribution
spec, after which the "registry-win-tp3.docker.io" ceased to exist, and
removed from the engine through docker/docker PR 21100.
However, the `ElectAuthServer` was left in place, quoting from that PR;
> make the client check which default registry the daemon uses is still
> more correct than leaving it up to the client, even if it won't technically
> matter after this PR. There may be some backward compatibility scenarios
> where `ElectAuthServer` [sic] is still helpful.
That comment was 5 years ago, and given that the engine and cli are
released in tandem, and the default registry is not configurable, we
can save the extra roundtrip to the daemon by using a fixed value.
This patch deprecates the `ElectAuthServer` function, and makes it
return the default registry without calling (potentially expensie)
`/info` API endpoint.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
With this change all `inspect` commands will output a compact JSON
representation of the elements, the default format (indented JSON) stays the
same.
Signed-off-by: Djordje Lukic <djordje.lukic@docker.com>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
including all the directives and a link to the documentation.
Signed-off-by: Silvin Lubecki <silvin.lubecki@docker.com>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Once upon a time, there was a website named ["The Docker index"][2]; a complimentary
service for users of Docker, provided by dotCloud. The Docker Index was the place
to find and explore pre-made container images, and allowed you to [share your
images and download them][1]. The Docker Index evolved rapidly, and gained new
features, such as [Trusted Images][3], and "stars" to rank your favorite images.
The website also provided an API, which allowed you to search images, even from
the comfort of your `docker` CLI. Things moved fast in container-land, and while
there was an API to use, it was still a work in progress. While the Docker Index
allowed users to "star" images, the search API did not rank results accordingly.
As any engineer knows, there's no problem that can't be solved with some elbow-
grease and a piece of Duct tape, so while the Docker Index team worked on making
the search API better, the `docker` engine [fixed the problem on the client side][4]
Years went by, and the Docker Index API became the "registry V1" specification,
including search. The registry got a major "v2" rewrite and became the [OCI Distribution
Spec][5], and Docker Index became Docker Hub, which included V2 and V3 search APIs.
The V1 search API continued to be supported, as it was the only documented API
for registries, but improvements were made, including ranking of search results.
Duct tape is durable, and even though improvements were made, the Docker client
continued to sort the results as well. Unfortunately, this meant that search
results on the command-line were ranked different from their equivalent on the
registry (such as Docker Hub).
This patch removes the client-side sorting of results, using the order in which
the search API returned them to (finally) celebrate the work of the engineers
working on the search API, also when used from the command-line.
[1]: https://web.archive.org/web/20130708004229/http://docker.io/
[2]: https://web.archive.org/web/20130623223614/https://index.docker.io/
[3]: https://web.archive.org/web/20140208001647/https://index.docker.io/
[4]: 1669b802cc
[5]: https://github.com/opencontainers/distribution-spec
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
With this change it is now possible to give a relative path to the --volume and
--mount flags.
$ docker run --mount type=bind,source=./,target=/test ...
$ docker run -v .:/test ...
Fixes#1203
Signed-off-by: Djordje Lukic <djordje.lukic@docker.com>
Changed `matcher.Matches(file)` to `matcher.MatchesOrParentMatches(file)`:
cli/command/image/build/context.go:95:9: SA1019: matcher.Matches is deprecated: This implementation is buggy (it only checks a single parent dir against the pattern) and will be removed soon. Use either MatchesOrParentMatches or MatchesUsingParentResults instead. (staticcheck)
return matcher.Matches(file)
^
And updated a test to match the JSON omitting empty RootFS.Type fields (in
practice, this field should never be empty in real situations, and always
be "layer"). Changed the test to use subtests to easier find which case
is failing.
full diff: 343665850e...83b51522df
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The information in this struct was basically fixed (there's
some discrepancy around the "DefaultVersion" which, probably,
should never vary, and always be set to the Default (maximum)
API version supported by the client.
Experimental is now always enabled, so this information did
not require any dynamic info as well.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This was there for historic reasons (I think `goimports` expected this,
and we used to have a linter that wanted it), but it's not needed, so
let's remove it (to make my IDE less complaining about unneeded aliases)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Not a fan of aliases, but unfortunately they're sometimes needed. We import both
docker/docker/registry and docker/registry and api/types/registry, so I looked
for which one to continue using an alias, and this was the one "least" used,
and which already used this alias everywhere, except for two places.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Just `config` as name for the package should work; this also revealed that one
file was importing the same package twice.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Previously, `version: "3"` was equivalent to `version: "3.0"`, which
caused confusion for many users, as they expected it to be "3.x".
docker-compose and docker compose (v2) have adopted the compose-spec
(https://compose-spec.io), which no longer has a version field in
the compose file, and always picks the "latest" supported version.
This changes how `docker stack` interprets "major" version numbers
specified in compose-files:
When only the major version ("3") is specified, it is now equivalent
to "3.x" (latest supported v3 schema).
Compose-files that specify both major and minor version (e.g. "3.0"
or "3.1") continue to use the existing behavior; validation is down-
graded to the specified version and will produce an error if options
are used that are not supported in that schema version. This allows
users to locally verify that a composse-file does not use options
that are not supported in the intended deployment environment (for
example if the deploy environment only supports older versions of
the schema).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Sebastiaan van Stijn
Nicolas De loof
Sebastiaan van Stijn
Djordje Lukic
Silvin Lubecki
Gleb Stsenov
Chee Hau Lim