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>
Adding a copy of the 3.9 schema, with only the version-string changed.
This makes it easier to find changes since 3.9, which are added after
this.
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>
As for top-level key, any 3rd-level key which starts with `x-` will be
ignored by compose. This allows for users to:
* include additional metadata in their compose files
* create YAML anchor objects that can be re-used in other parts of the config
This matches a similar feature in the swagger spec definition:
https://swagger.io/specification/#specificationExtensions
This means a composefile like the following is valid
```
verison: "3.7"
services:
foo:
image: foo/bar
x-foo: bar
network:
bar:
x-bar: baz
```
It concerns services, volumes, networks, configs and secrets.
Signed-off-by: Vincent Demeester <vincent@sbr.pm>
Fix tests that failed when using cmp.Compare()
internal/test/testutil/assert
InDelta
Fix DeepEqual with kube metav1.Time
Convert some ErrorContains to assert
Signed-off-by: Daniel Nephin <dnephin@docker.com>