This is admittedly "scope creep" for a job that was originally intended
only to run the end-to-end tests, but we have a separate e2etest job
specifically because some of these tests interact with the live OpenTofu
Registry and certain GitHub repositories and so it's nice to have these
external dependencies isolated into their own job so that outages of any
of these external services should only affect this one test job.
The TF_ACC=1-constrained tests in packages initwd and registry are set up
that way because they too interact with OpenTofu Registry and GitHub
repositories, so grouping these together retains the idea of limited
these external dependencies to only one job while giving us a little more
test coverage for our PR checks.
The motivation for doing this now is that both of these packages had
acceptance tests that had been broken by changes in the past and we didn't
notice because nothing was routinely running these tests:
- package registry had been failing ever since OpenTofu existed because
one of its tests seems to have been depending on an undocumented registry
protocol feature that OpenTofu Registry has never implemented
- package initwd got broken more recently by a change to use a dependency
inversion style for the module installer's use of module registry client
and package fetcher, but these particular tests were not passing in
working clients for the module installer to use.
Both of those problems were already fixed in earlier commits, and so this
is just an attempt to avoid similar problems happening again in future.
(This doesn't address the more common case of acceptance tests that require
live credentials to access a service that doesn't support anonymous access.
Those will still need to run manually in development environments because
we cannot pass live credentials to a job that runs in response to
third-party pull requests.)
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
For anything we run as PR checks it should always be straightforward to
recreate any failure locally in a development environment, so instead of
using the golangci/golangci-lint-action GitHub action (whose behavior
is nontrivial and annoying to reproduce outside of GitHub Actions) we'll
just use our existing Makefile target as part of the check run, matching
how we deal with most other similar concerns in this GitHub Actions
workflow.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
This is just a routine upgrade, keeping us up-to-date with the latest
linter changes. This already passes when run on Linux.
We know that currently the lint checks aren't passing on Windows even with
v2.4.0, and this doesn't do anything about that but it does mean that once
we make the linters pass on Windows we'll be dealing with the full set
supported in v2.6.0, rather than potentially having to do this across
two commits.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
The v1.11 series will now continue maintenence in the v1.11 branch, and
so this branch is now tracking the work for the forthcoming v1.12 series.
Signed-off-by: Christian Mesh <christianmesh1@gmail.com>
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>
In our checks workflow we try to skip running unit tests unless Go files
have changed, but we didn't previously consider "go.mod" and "go.sum" as
"Go files".
Changes to our dependencies can change the results of our tests, so we
should run tests even if only the dependencies have changed.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
The main motivation here is that we now use PRs rather than issues to
represent RFCs that have not yet been approved, and so the ranking of
issues labeled "rfc" was misleading to include. All of the issues that
were labeled "rfc" that were not "RFC Tracker" issues under our newer
process are also labeled as "enhancement" so they will be included under
the "Top Enhancements" ranking.
While I was tweaking this anyway I also added a short note to the top
explaining how these rankings are generated and removed some of the
visual clutter from the suffixes of the individual list items, which
tended to get wrapped oddly for issues with longer titles.
Finally, the "script" is tweaked a little to do its API requests
anonymously when GITHUB_TOKEN isn't set, which makes it easier to test
locally without accidentally clobbering any real issues (since anonymous
requests cannot modify anything). To _actually_ test this locally I
temporarily made it print its output to stdout, but that particular part
is removed for the final submission.
Signed-off-by: Martin Atkins <mart@degeneration.co.uk>
