Some tests had to be skipped as there's some issues to address, and
some of the result-types cannot be mocked / stubbed.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
It's adding a slight indirection by constructing a function when called,
but makes the completion functions more consistent, the signature easier
to read, and making the return type a [cobra.CompletionFunc] makes it
more transparent what it's intended for, and helps discovery of functions
that provide completion.
[cobra.CompletionFunc]: https://pkg.go.dev/github.com/spf13/cobra#CompletionFunc
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
It's adding a slight indirection by constructing a function when called,
but makes the completion functions more consistent, the signature easier
to read, and making the return type a [cobra.CompletionFunc] makes it
more transparent what it's intended for, and helps discovery of functions
that provide completion.
[cobra.CompletionFunc]: https://pkg.go.dev/github.com/spf13/cobra#CompletionFunc
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
It's adding a slight indirection by constructing a function when called,
but makes the completion functions more consistent, the signature easier
to read, and making the return type a [cobra.CompletionFunc] makes it
more transparent what it's intended for, and helps discovery of functions
that provide completion.
[cobra.CompletionFunc]: https://pkg.go.dev/github.com/spf13/cobra#CompletionFunc
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
It's adding a slight indirection by constructing a function when called,
but makes the completion functions more consistent, the signature easier
to read, and making the return type a [cobra.CompletionFunc] makes it
more transparent what it's intended for, and helps discovery of functions
that provide completion.
[cobra.CompletionFunc]: https://pkg.go.dev/github.com/spf13/cobra#CompletionFunc
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Using `--platform=linux` or `--platform=windows` is not commonly
used (or recommended). Let's remove these from the list of suggested
platforms.
We should tweak this completion further, and sort the list based
on the daemon's platform (putting linux first for a Linux daemon,
and windows first on a Windows daemon), possibly with the correct
architecture (and os-version) included, but we don't yet provide
that information in `/_ping`.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Cobra now defines a CompletionFunc for the same, so we can alias
it to that, and stop using our own definition.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Previously, multiple suggestions were provided when completing
commands like `run`, `history` and `push`. This change
limits completion to a single suggestion for the above and 2 suggestions for `tag`
Signed-off-by: Mohammed Aminu Futa <mohammedfuta2000@gmail.com>
go1.22 and up now produce a unique variable in loops, tehrefore no longer
requiring to capture the variable manually;
service/logs/parse_logs_test.go:50:3: The copy of the 'for' variable "tc" can be deleted (Go 1.22+) (copyloopvar)
tc := tc
^
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Add a utility for completing platform strings.
Platforms offers completion for platform-strings. It provides a non-exhaustive
list of platforms to be used for completion. Platform-strings are based on
[runtime.GOOS] and [runtime.GOARCH], but with (optional) variants added. A
list of recognised os/arch combinations from the Go runtime can be obtained
through "go tool dist list".
Some noteworthy exclusions from this list:
- arm64 images ("windows/arm64", "windows/arm64/v8") do not yet exist for windows.
- we don't (yet) include `os-variant` for completion (as can be used for Windows images)
- we don't (yet) include platforms for which we don't build binaries, such as
BSD platforms (freebsd, netbsd, openbsd), android, macOS (darwin).
- we currently exclude architectures that may have unofficial builds,
but don't have wide adoption (and no support), such as loong64, mipsXXX,
ppc64 (non-le) to prevent confusion.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
It's an alias for cobra.FixedCompletions but takes a variadic list
of strings, so that it's not needed to construct an array for this.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
EnvVarNames offers completion for environment-variable names. This
completion can be used for "--env" and "--build-arg" flags, which
allow obtaining the value of the given environment-variable if present
in the local environment, so we only should complete the names of the
environment variables, and not their value. This also prevents the
completion script from printing values of environment variables
containing sensitive values.
For example;
export MY_VAR=hello
docker run --rm --env MY_VAR alpine printenv MY_VAR
hello
Before this patch:
docker run --env GO
GO111MODULE=auto GOLANG_VERSION=1.21.12 GOPATH=/go GOTOOLCHAIN=local
With this patch:
docker run --env GO<tab>
GO111MODULE GOLANG_VERSION GOPATH GOTOOLCHAIN
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This is just a convenience function to allow defining completion to
use the default (complete with filenames and directories).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The completion functions only need the API-client, and not all of
the CLI. However, passing the API-client as argument would mean
that the API-client is initialized early, which may not be what
we want, so instead, defining an APIClientProvider interface to
preserve the behavior of initializing when needed only.
While updating, also simplify stack.format to only require an
io.Writer.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
