Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 5f822b36d3f5ecd670d92f693bdee43df366c6fe)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This package has moved to a separate module. Also added linting
rules to prevent accidental reintroduction.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit c116af7b82b7f9af8bb73ff84483d2224405a959)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Replaces uses of the github.com/mitchellh/mapstructure module, which
was deprecated by the owner and moved to new maintainership at
github.com/go-viper/mapstructure.
The old module is still referenced as indirect dependency (through
docker/cli and theupdateframework/notary), but not used in code, and
should eventually go away.
full diff: https://github.com/compose-spec/compose-go/compare/v2.1.1...v2.1.2
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This adds an alias for `--check` that causes it to behave the same as
`--call=check`. This is done using `BoolFunc` to call a function when
the option is seen and to set it to the correct value. This should allow
command line flags like `--check --call=targets` to work correctly (even
though they conflict) by making it so the first invocation sets the
print function to `check` and the second overwrites the first. This is
the expected behavior for these types of boolean flags.
`BoolFunc` itself is part of the standard library flags package, but
never seems to have made it into pflag possibly because it was added in
go 1.21.
https://pkg.go.dev/flag#FlagSet.BoolFunc
Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.com>
Because sandbox is closed down when the main test
that created the sandbox returns it can't have subtests
that set themselves as parallel as they would continue
to run in a different lifecycle.
Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com>
Update buildkit dependency to v0.14.0-rc1. Update the tracing
infrastructure to use the new detect API which updates how the delegated
exporter is configured.
Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.com>
This metric records the number of times it sees a lint warning in the
progress stream and categorizes the number of times each rule has been
triggered. This will only record whether a lint warning was triggered
and not whether the linter was even used or which rules were present.
That information isn't presently part of the stream.
With this change, we might be reaching some of the limitations that
spying on the progress stream gives us for metrics and may want to
consider another way for the build to communicate metrics back to the
client.
Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.com>
