Rewrite the custom user agent to use the new options that were added
in the cli:
- plugin.Run now accepts custom CLI options to allow customizing the CLI's
- cli/command now has a WithUserAgent option to customize the CLI's user-
agent, allowing it to be overridden from the default.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The Apply method was added when CLI options for constructing the CLI were
rewritten into functional options in [cli@7f207f3]. There was no mention
in the pull request of this method specifically, and we want to remove or
reduce functions that mutate the CLI configuration after initialization
if possible (and likely remove the `Apply` method).
This patch removes the use of the `Apply` function as an intermediate step;
improvements will be made in the CLI itself for a more solid implementation.
[cli@7f207f3]: 7f207f3f95
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This warning was added in [moby@4a8b3ca] to print a warning when building
Linux images from a Windows client. Window's filesystem does not have an
"executable" bit, which mean that, for example, copying a shell script
to an image during build would lose the executable bit. So for Windows
clients, the executable bit would be set on all files, unconditionally.
Originally this was detected in the client, which had direct access to
the API response headers, but when refactoring the client to use a common
library in [moby@535c4c9], this was refactored into a `ImageBuildResponse`
wrapper, deconstructing the API response into an `io.Reader` and a string
field containing only the `OSType` header.
This was the only use and only purpose of the `OSType` field, and now that
BuildKit is the default builder for Linux images, this warning didn't get
printed unless BuildKit was explicitly disabled.
This patch removes the warning, so that we can potentially remove the
field, or the `ImageBuildResponse` type altogether.
[moby@4a8b3ca]: 4a8b3cad60
[moby@535c4c9]: 535c4c9a59
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The github.com/mitchellh/mapstructure module was archived and is no longer
maintained. This module has moved to github.com/go-viper/mapstructure,
which updated to v2, with a minor breaking change in v2.0;
> Error is removed in favor of errors.Join (backported from Go 1.20 to
> preserve compatibility with earlier versions)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The official nginx images set STOPSIGNAL to SIGQUIT which dumps core.
Set it to SIGTERM to avoid dumping core on e2e tests.
Signed-off-by: Ricardo Branco <rbranco@suse.de>
Co-authored-by: Allie Sadler <102604716+aevesdocker@users.noreply.github.com>
Signed-off-by: Nicolas De loof <nicolas.deloof@gmail.com>
Signed-off-by: Nicolas De Loof <nicolas.deloof@gmail.com>
- Use a errgroup.Group and add a appendErr utility to not fail-fast,
but collect errors.
- replace doneCh for a global context to cancel goroutines
- Commented out attachCtx code, as it didn't appear to be functional
(as it wouldn't be cancelled).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The go-multierror Group is just a shallow wrapper around sync.WaitGroup;
https://github.com/hashicorp/go-multierror/blob/v1.1.1/group.go#L5-L38
This patch replaces the go-multierror.Group for a sync.WaitGroup (we
probably don't need to limit concurrency for this one) and stdlib multi-
errors.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The go-multierror Group is just a shallow wrapper around sync.WaitGroup;
https://github.com/hashicorp/go-multierror/blob/v1.1.1/group.go#L5-L38
It does not limit concurrency, but handles synchronisation to collect
all errors (if any) in a go-multierror.
This patch replaces the go-multierror.Group for a sync.ErrGroup (which
is slightly easier to use, and does allow for limiting concurrency if
wanted), and a basic slice with mutex to collect the errors and to produce
a stdlib multi-error through errors.Join
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
