mirror of
https://github.com/opentffoundation/opentf.git
synced 2025-12-19 09:48:32 -05:00
e74bf2d0a1
Previously the Go toolchain had no explicit support for "tools" and so we used the typical Go community workaround of adding "tools.go" files (two, for some reason) that existed only to trick the Go toolchain into considering the tools as dependencies we could track in go.mod. Go 1.24 introduced explicit support for tracking tools as part of go.mod, and the ability to run those using "go tool" instead of "go run", and so this commit switches us over to using that strategy for everything we were previously managing in tools.go. There are some intentional exceptions here: - The protobuf-compile script can't use "go tool" or "go run" because the tools in question are run only indirectly through protoc. However, we do still use the "tool" directive in go.mod to tell the Go toolchain that we depend on those tools, so that it'll track which versions we are currently using as part of go.mod. - Our golangci-lint Makefile target uses "go run" to run a specific version of golangci-lint. We _intentionally_ don't consider that tool to be a direct dependency of OpenTofu because it has a lot of indirect dependencies that would pollute our go.mod file. Therefore that continues to use "go run" after this commit. - Both of our tools.go files previously referred to github.com/nishanths/exhaustive , but nothing actually appears to be using that tool in the current OpenTofu tree, so it's no longer a dependency after this commit. All of the dependencies we have _only_ for tools are now classified as "indirect" in the go.mod file. This is the default behavior of the Go toolchain and appears to be motivated by making it clearer that these modules do not contribute anything to the runtime behavior of OpenTofu. This also corrected a historical oddity in our go.mod where for some reason the "indirect" dependencies had been split across two different "require" directives; they are now all grouped together in a single directive. Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
47 lines
1.4 KiB
Go
47 lines
1.4 KiB
Go
// Copyright (c) The OpenTofu Authors
|
|
// SPDX-License-Identifier: MPL-2.0
|
|
// Copyright (c) 2023 HashiCorp, Inc.
|
|
// SPDX-License-Identifier: MPL-2.0
|
|
|
|
package moduletest
|
|
|
|
// Status represents the status of a test case, and is defined as an iota within
|
|
// this file.
|
|
//
|
|
// The order of the definitions matter as different statuses do naturally take
|
|
// precedence over others. A test suite that has a mix of pass and fail statuses
|
|
// has failed overall and therefore the fail status is of higher precedence than
|
|
// the pass status.
|
|
//
|
|
// See the Status.Merge function for this requirement being used in action.
|
|
//
|
|
//go:generate go tool golang.org/x/tools/cmd/stringer -type=Status status.go
|
|
type Status int
|
|
|
|
const (
|
|
Pending Status = iota
|
|
Skip
|
|
Pass
|
|
Fail
|
|
Error
|
|
)
|
|
|
|
// Merge compares two statuses and returns a status that best represents the two
|
|
// together.
|
|
//
|
|
// This should be used to collate the overall status of a test file or test
|
|
// suite from the collection of test runs that have been executed.
|
|
//
|
|
// Essentially, if a test suite has a bunch of failures and passes the overall
|
|
// status would be failure. If a test suite has all passes, then the test suite
|
|
// would be pass overall.
|
|
//
|
|
// The implementation basically always returns the highest of the two, which
|
|
// means the order the statuses are defined within the iota matters.
|
|
func (status Status) Merge(next Status) Status {
|
|
if next > status {
|
|
return next
|
|
}
|
|
return status
|
|
}
|