This is a follow-up to 0e73168b7e
This repository is not yet a module (i.e., does not have a `go.mod`). This
is not problematic when building the code in GOPATH or "vendor" mode, but
when using the code as a module-dependency (in module-mode), different semantics
are applied since Go1.21, which switches Go _language versions_ on a per-module,
per-package, or even per-file base.
A condensed summary of that logic [is as follows][1]:
- For modules that have a go.mod containing a go version directive; that
version is considered a minimum _required_ version (starting with the
go1.19.13 and go1.20.8 patch releases: before those, it was only a
recommendation).
- For dependencies that don't have a go.mod (not a module), go language
version go1.16 is assumed.
- Likewise, for modules that have a go.mod, but the file does not have a
go version directive, go language version go1.16 is assumed.
- If a go.work file is present, but does not have a go version directive,
language version go1.17 is assumed.
When switching language versions, Go _downgrades_ the language version,
which means that language features (such as generics, and `any`) are not
available, and compilation fails. For example:
# github.com/docker/cli/cli/context/store
/go/pkg/mod/github.com/docker/cli@v25.0.0-beta.2+incompatible/cli/context/store/storeconfig.go:6:24: predeclared any requires go1.18 or later (-lang was set to go1.16; check go.mod)
/go/pkg/mod/github.com/docker/cli@v25.0.0-beta.2+incompatible/cli/context/store/store.go:74:12: predeclared any requires go1.18 or later (-lang was set to go1.16; check go.mod)
Note that these fallbacks are per-module, per-package, and can even be
per-file, so _(indirect) dependencies_ can still use modern language
features, as long as their respective go.mod has a version specified.
Unfortunately, these failures do not occur when building locally (using
vendor / GOPATH mode), but will affect consumers of the module.
Obviously, this situation is not ideal, and the ultimate solution is to
move to go modules (add a go.mod), but this comes with a non-insignificant
risk in other areas (due to our complex dependency tree).
We can revert to using go1.16 language features only, but this may be
limiting, and may still be problematic when (e.g.) matching signatures
of dependencies.
There is an escape hatch: adding a `//go:build` directive to files that
make use of go language features. From the [go toolchain docs][2]:
> The go line for each module sets the language version the compiler enforces
> when compiling packages in that module. The language version can be changed
> on a per-file basis by using a build constraint.
>
> For example, a module containing code that uses the Go 1.21 language version
> should have a `go.mod` file with a go line such as `go 1.21` or `go 1.21.3`.
> If a specific source file should be compiled only when using a newer Go
> toolchain, adding `//go:build go1.22` to that source file both ensures that
> only Go 1.22 and newer toolchains will compile the file and also changes
> the language version in that file to Go 1.22.
This patch adds `//go:build` directives to those files using recent additions
to the language. It's currently using go1.19 as version to match the version
in our "vendor.mod", but we can consider being more permissive ("any" requires
go1.18 or up), or more "optimistic" (force go1.21, which is the version we
currently use to build).
For completeness sake, note that any file _without_ a `//go:build` directive
will continue to use go1.16 language version when used as a module.
[1]: 58c28ba286/src/cmd/go/internal/gover/version.go (L9-L56)
[2]; https://go.dev/doc/toolchain#:~:text=The%20go%20line%20for,file%20to%20Go%201.22
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 70216b662d)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
(cherry picked from commit fe7afb700f)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Since Swarm does not use the `build` section, there's no reason to validate properties here.
This makes it so we don't have to keep updating the schema in the CLI to support properties
added in the Compose Spec for build, and does not imply any new feature support since Swarm
does not consider this section.
Signed-off-by: Laura Brehm <laurabrehm@hey.com>
Various fixes:
- Don't capitalize error messages
- Rename variables that collided with imports or types
- Prefer assert.Check over assert.Assert to prevent tests covering multiple
cases from failing early
- Fix inconsistent order of expected <--> actual, which made it difficult to
check which output was the expected output.
- Fix formatting of some comments
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The version was originally added in 570ee9cb54,
at the time the `expected` config did not have a `version:` field. A later
refactor in 0cf2e6353a updated the `expected`
config to have a `version:` included. However, the test was not updated,
which now resulted in the test using a compose file with a duplicate version
field:
version: '3.10'
version: "3.10"
services:
foo:
build:
This issue was masked by `yaml.Unmarshal()` from `gopkg.in/yaml.v2` which
silently ignores the duplicate, taking the value of the last occurrence. When
upgrading to `gopkg.in/yaml.v3`, the duplicate value resulted in an error:
yaml: unmarshal errors:
line 2: mapping key "version" already defined at line 1
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Looks like the linter uses an explicit -lang, which (for go1.19)
results in some additional formatting for octal values.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Older versions of Go do not format these comments, so we can already
reformat them ahead of time to prevent gofmt linting failing once
we update to Go 1.19 or up.
Result of:
gofmt -s -w $(find . -type f -name '*.go' | grep -v "/vendor/")
With some manual adjusting.
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>
The compose spec (https://compose-spec.io) defines the version to be optional,
and implementations of the spec to check for supported attributes instead.
While this change does not switch the `docker stack` implementation to use the
compose-spec, it makes it function more similar. Previously, omitting a version
number would either produce an error (as the field was required), or switched
the handling to assume it was version 1.0 (which is deprecated).
With this change, compose files without a version number will be handled as
the latest version supported by `docker stack` (currently 3.10). This allows
users that work with docker-compose or docker compose (v2) to deploy their
compose file, without having to re-add a version number. Fields that are
not supported by stackes (schema 3.10) will still produce an error.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Both libaries provide similar functionality. We're currently using
Google Shlex in more places, so prefering that one for now, but we
could decide to switch to mattn/go-shellwords in future if that
library is considered better (it looks to be more actively maintained,
but that may be related to it providing "more features").
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This is not currently used by the CLI, but can be used by
docker compose to bring parity on this feature with the
compose v2.4 schema.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
67ebcd6dcf added an exception for
the "host-gateway" magic value to the validation rules, but didn't
add thise value to any of the tests.
This patch adds the magic value to tests, to verify the validation
is skipped for this magic value.
Note that validation on the client side is "optional" and mostly
done to provide a more user-friendly error message for regular
values (IP-addresses).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Before this change, this would cause a panic:
docker run -it --rm -v 1:/1 alpine
panic: runtime error: index out of range
goroutine 1 [running]:
github.com/docker/cli/cli/compose/loader.isFilePath(0xc42027e058, 0x1, 0x557dcb978c20)
...
After this change, a correct error is returned:
docker run -it --rm -v 1:/1 alpine
docker: Error response from daemon: create 1: volume name is too short, names should be at least two alphanumeric characters.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Added transforms for when merging compose overrides to preserve the
functionality that was broken by bumping mergo to v1.3.8
This includes:
- Special transform for ulimits so single overrides both soft/hard and
the reverse
- Special transform for service network configs so the override replaces
all aliases
Signed-off-by: Nick Adcock <nick.adcock@docker.com>
```
cli/compose/loader/merge.go:64:41: Using a reference for the variable on range scope `overrideService` (scopelint)
if err := mergo.Merge(&baseService, &overrideService, mergo.WithAppendSlice, mergo.WithOverride, mergo.WithTransformers(specials)); err != nil {
^
cli/compose/loader/loader_test.go:1587:28: Using the variable on range scope `testcase` in function literal (scopelint)
config, err := loadYAML(testcase.yaml)
^
cli/compose/loader/loader_test.go:1590:58: Using the variable on range scope `testcase` in function literal (scopelint)
assert.Check(t, is.DeepEqual(config.Services[0].Init, testcase.init))
^
```
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This test was intending to run all tests, but didn't, which was
caught by golangci-lint;
cli/compose/loader/windows_path_test.go:46:17: SA4010: this result of append is never used, except maybe in other appends (staticcheck)
tests := append(isabstests, winisabstests...)
^
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This is currently just a copy of the v3.8 schema, in preparation
of new features to be added in the new schema.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
When deploying a stack using a relative path as bind-mount
source in the compose file, the CLI converts the relative
path to an absolute path, relative to the location of the
docker-compose file.
This causes a problem when deploying a stack that uses
an absolute Windows path, because a non-Windows client will
fail to detect that the path (e.g. `C:\somedir`) is an absolute
path (and not a relative directory named `C:\`).
The existing code did already take Windows clients deploying
a Linux stack into account (by checking if the path had a leading
slash). This patch adds the reverse, and adds detection for Windows
absolute paths on non-Windows clients.
The code used to detect Windows absolute paths is copied from the
Golang filepath package;
1d0e94b1e1/src/path/filepath/path_windows.go (L12-L65)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This maps the `--template-driver` flag on secret and config creation.
Signed-off-by: Vincent Demeester <vincent@sbr.pm>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This should make it easier for people to write custom composefile
parser without duplicating too much code. It takes the default
transformers and any additional number of transformer for any
types. That way it's possible to transform a `cli/compose` map into a
custom type that would use some of `cli/compose` types and its own.
Signed-off-by: Vincent Demeester <vincent@sbr.pm>
Sebastiaan van Stijn
Paweł Gronowski
Laura Brehm
Sebastiaan van Stijn
Drew Erny
mspiess
Stoica-Marcu Floris-Andrei
Silvin Lubecki
Nick Adcock
Djordje Lukic
Silvin Lubecki
Ulysses Souza
Sune Keller
Vincent Demeester
Olli Janatuinen
Mindaugas Rukas
Joffrey F
Arash Deshmeh