Commit Graph

16 Commits

Author SHA1 Message Date
Sebastiaan van Stijn 70216b662d
add //go:build directives to prevent downgrading to go1.16 language
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>
2023-12-14 15:03:46 +01:00
Sebastiaan van Stijn 0e73168b7e
golangci-lint: revive: enable use-any
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2023-11-20 19:52:46 +01:00
Sebastiaan van Stijn 3499669e18
cli/flags: merge CommonOptions into ClientOptions
CommonOptions was inherited from when the cli and daemon were in the same
repository, and some options would be shared between them. That's no longer
the case, and some options are even "incorrect" (for example, while the
daemon can be configured to run on multiple hosts, the CLI can only connect
with a single host / connection). This patch does not (yet) address that,
but merges the CommonOptions into the ClientOptions.

An alias is created for the old type, although it doesn't appear there's
any external consumers using the CommonOptions type (or its constructor).

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2022-11-22 12:32:18 +01:00
Sebastiaan van Stijn de6020a240
cli/context/store: simplify error handling, and make it more idiomatic
The package defined various special errors; these errors existed for two reasons;

- being able to distinguish "not found" errors from other errors (as "not found"
  errors can be ignored in various cases).
- to be able to update the context _name_ in the error message after the error
  was created. This was needed in cases where the name was not available at the
  location where the error was produced (e.g. only the "id" was present), and
  the helpers to detect "not found" errors did not support wrapped errors (so
  wrapping the error with a "name" could break logic); a `setContextName` interface
  and corresponding `patchErrContextName()` utility was created for this (which
  was a "creative", but not very standard approach).

This patch:

- Removes the special error-types, replacing them with errdefs definitions (which
  is a more common approach in our code-base to detect error types / classes).
- Removes the internal utilities for error-handling, and deprecates the exported
  utilities (to allow external consumers to adjust their code).
- Some errors have been enriched with detailed information (which may be useful
  for debugging / problem solving).
- Note that in some cases, `patchErrContextName()` was called, but the code
  producing the error would never return a `setContextName` error, so would
  never update the error message.

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2022-09-30 11:19:25 +02:00
Sebastiaan van Stijn 28b0aa9f1a
replace uses of deprecated env.Patch()
Also removing redundant defer for env.PatchAll(), which is now automatically
handled in t.Cleanup()

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2022-09-22 17:28:07 +02:00
Sebastiaan van Stijn 6874c2e80b
cli/command: remove unused args from ResolveDefaultContext()
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2022-07-21 18:11:48 +02:00
Sebastiaan van Stijn 3f7e7bf9d2
cli/command: remove deprecated io/ioutil and use t.TempDir()
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2022-02-25 15:42:14 +01:00
Sebastiaan van Stijn 6ea2767289
config: mark stackOrchestrator option as deprecated
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2022-02-24 13:35:03 +01:00
Nicolas De Loof 193ede9b12
remove obsolete mutli-orchestrator support
Signed-off-by: Nicolas De Loof <nicolas.deloof@gmail.com>
2022-02-22 15:28:12 +01:00
Sebastiaan van Stijn 2c0e93063b
bump gotest.tools v3.0.1 for compatibility with Go 1.14
full diff: https://github.com/gotestyourself/gotest.tools/compare/v2.3.0...v3.0.1

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2020-02-23 00:28:55 +01:00
Sebastiaan van Stijn 73dcf50d5a
cli/command: fix formatting of comments, and minor linting issues
Comments should have a leading space unless the comment is
for special purposes (go:generate, nolint:)

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2020-01-16 12:47:12 +01:00
Ian Campbell 520be05c49 Dynamically register kubernetes context store endpoint type.
This removes the need for the core context code to import
`github.com/docker/cli/cli/context/kubernetes` which in turn reduces the
transitive import tree in this file to not pull in all of Kubernetes.

Note that this means that any calling code which is interested in the
kubernetes endpoint must import `github.com/docker/cli/cli/context/kubernetes`
itself somewhere in order to trigger the dynamic registration. In practice
anything which is interested in Kubernetes must import that package (e.g.
`./cli/command/context.list` does for the `EndpointFromContext` function) to do
anything useful, so this restriction is not too onerous.

As a special case a small amount of Kubernetes related logic remains in
`ResolveDefaultContext` to handle error handling when the stack orchestrator
includes Kubernetes. In order to avoid a circular import loop this hardcodes
the kube endpoint name.

Similarly to avoid an import loop the existing `TestDefaultContextInitializer`
cannot continue to unit test for the Kubernetes case, so that aspect of the
test is carved off into a very similar test in the kubernetes context package.

Lastly, note that the kubernetes endpoint is now modifiable via
`WithContextEndpointType`.

Signed-off-by: Ian Campbell <ijc@docker.com>
2019-05-20 13:28:11 +01:00
Ian Campbell f820766f6a Export `DefaultContextStoreConfig()` and `ResolveDefaultContext()`
These are needed by any dynamically registered (via
`RegisterDefaultStoreEndpoints`) endpoint type to write a useful/sensible unit
test.

Signed-off-by: Ian Campbell <ijc@docker.com>
2019-05-20 13:28:11 +01:00
Ian Campbell 1433e27420 Allow dynamically registered context endpoint to provide their defaults.
Previously an endpoint registered using `RegisterDefaultStoreEndpoints` would
not be taken into consideration by `resolveDefaultContext` and so could not
provide any details.

Resolve this by passing a `store.Config` to `resolveDefaultContext` and using
it to iterate over all registered endpoints. Any endpoint can ensure that their
type implements the new `EndpointDefaultResolver` in order to provide a default.

The Docker and Kubernetes endpoints are special cased, shortly the Kubernetes
one will be refactored to be dynamically registered.

Signed-off-by: Ian Campbell <ijc@docker.com>
2019-05-20 13:28:11 +01:00
Simon Ferquel a3efd5d195 Cleanup context store interfaces
This remove the term "context" from context store interfaces, to make
them more concise

Signed-off-by: Simon Ferquel <simon.ferquel@docker.com>
2019-04-18 15:49:36 +02:00
Jean-Christophe Sirot b3aa17187f Make default context behaves like a real context:
- when using "--context default" parameter
- when printing the list of contexts
- when exporting the default context to a tarball

Signed-off-by: Jean-Christophe Sirot <jean-christophe.sirot@docker.com>
(+1 squashed commit)
Squashed commits:
[20670495] Fix CLI initialization for the `docker stack deploy --help` command and ensure that the dockerCli.CurrentContext() always returns a non empty context name (default as a fallback)
Remove now obsolete code handling empty string context name
Minor code cleanup

Signed-off-by: Jean-Christophe Sirot <jean-christophe.sirot@docker.com>
2019-03-18 11:45:46 +01:00