By changing the folder changie uses for the changelog we can
make sure that users can put the changelog entries into a specific
folder based on if the change will be backported. This way it will
only appear in the patch release of the maintenance branch and not
in the changelog of the current development branch.
Historically it's been hard for us to keep on top of dependency upgrades
as a matter of course because it's unclear which code owners might be
affected by or responsible for an upgrade of each module.
After trying a few different techniques to try to mitigate this, the most
promising one seems to be to tell the Go toolchain that each of these
components is a separate Go module, but then to stitch them all back
together again using replace directives so that we can mostly ignore these
module boundaries in everyday development.
The one case where we _do_ need to pay attention to these boundaries is
also the case where the separation is useful: upgrading a dependency of
any one of these modules might potentially force upgrading it for another
module too, and so the Go toolchain will help us notice that interaction
and we can immediately which code owners might need to be involved in
reviewing and testing that particular upgrade.
To make that process less onerous, this adds a new makefile target
"make syncdeps" which runs "go mod tidy" in all of the modules at once
and thus forces the toolchain to align their dependencies to the extent
required for them all to be linked together successfully, and to generate
go.mod and/or go.sum diffs that will match our configured code ownership
paths to trigger the appropriate code review requests.
Hopefully before too long we'll be able to move all the backends out into
provider plugins and delete the "legacy" module entirely and then this
oddness won't be needed anymore, but as long as we're all trying to play
together in this same sandbox this is a small amount of extra ceremony in
return for hopefully reducing the level of anxiety involved in keeping the
system's dependencies up to date more consistently.
* ci: Add test for copyright headers
* replace GHA workflow with make target (copyright)
This makes it reusable for outside of CI, such that anyone cloning the repo locally can still easily verify compliance before raising a PR.
* remove go:generate for copywrite
This should no longer be needed as we leverage copywrite via a shell script now.
* introduce make copyrightfix
Since we already specify a list of staticcheck rules to ignore in the
scripts/staticcheck.sh wrapper script, this hoists those preferences up to the
top of the package tree, so they also affect the staticcheck integration in
editors like VSCode. This avoids unnecessary yellow-squiggles for capitalized
error messages, and makes integrated linting much more useful.
protoc-gen-go generates non-style-compliant import directives, but since
those files are just generated anyway we don't need to worry too much
about what style they are in: the style that protoc-gen-go generates is
the canonical style for these ones.
At the risk of a little bit of hidden spooky action at a distance, this
will slightly change the behavior of the "goimports check" to compare
against the base branch of a PR rather than to origin/main if we happen
to find one of the environment variables that GitHub Actions sets
automatically in its runners. This is targeting our "checks.yml" workflow
in particular.
The intention here is to avoid misreporting files that haven't actually
changed when a PR is targeting a branch other than the main branch, such
as directly targeting a historical release branch.
We'll still run against origin/main when we're not running in GitHub
Actions, since that's _typically_ the correct branch to use for new
work, even if it will eventually get backported to a release branch.
The previous implementation of this check tried to accumulate all of the
changed files into a single big string and then run goimports once with
all of them, but that approach ran into problems for changesets of a
certain (platform-specific) size due to limits on maximum command line
length.
This new version instead uses bash arrays and runs goimports separately
for each of the files which appear to have changed relative to the
base branch. This is likely to be slower to complete for changesets that
have many different changed files, but it's better for it to be slow than
to return an error and fail to check some of the files.
Because we maintain multiple versions of Terraform across different
release branches, we aim to avoid creating needless differences between
the branches to maximize the chance of successful automatic backporting.
Part of that policy is that we don't make cross-cutting changes to respond
to deprecation of functions in upstream packages and instead we respond
to them gradually over time when we'd be changing the nearby code anyway,
or when new work requires using the replacement APIs.
In recognition of that, this turns of the staticcheck rule that would
otherwise force us to resolve all deprecations before moving forward with
any other change.
* Add goimports as a check to the Github commit actions
* check diff against main instead of last commit
* goimports should fix the problems
* fix up conditionals and wildcard matching
* specify origin/main in diff
* fetch main branch when checkout
* back to origin main
This is intended to eventually replace the CircleCI-based checks we use
as part of the PR process in this repository. We're already using GitHub
Actions for various other processes in this repository, so this change is
motivated by consistency of having all of our automation running in the
same system and written in the same language.
This is not a complete replacement for our CircleCI workflow yet, and
probably won't ever be because the CircleCI workflow contains some steps
that are arguably redundant with other processes we follow elsewhere.
However, the CircleCI workflow remains for now and won't be removed until
we're satisfied that enough of it is replicated by this GitHub Actions
workflow.
Running the tool this way ensures that we'll always run the version
selected by our go.mod file, rather than whatever happened to be available
in $GOPATH/bin on the system where we're running this.
This change caused some contexts to now be using a newer version of
staticcheck with additional checks, and so this commit also includes some
changes to quiet the new warnings without any change in overall behavior.
For now, only check the JSON views package, since this was the instance
that most recently tripped us up. There are a few dozen failures
elsewhere in Terraform which would need to be addressed before expanding
this to other packages.
We have a few different .proto files in this repository that all need to
get recompiled into .pb.go files each time we change them, but we were
previously handling that with some scripts that just assumed that protoc
and the relevant plugins were already installed on the system somewhere,
at the right versions.
In practice we've been constantly flopping between different versions of
these tools due to folks having different versions installed in their
development environments. In particular, the state of the .pb.go files
in the prior commit wasn't reproducible by any single version of the tools
because they've all slightly diverged from one another.
In the interests of being more consistent here and avoiding accidental
inconsistencies, we'll now centralize the protocol buffer compile steps
all into a single tool that knows how to fetch and install the expected
versions of the various tools we need and then run those tools with the
right options to get a stable result.
If we want to upgrade to either a newer protoc or a newer protoc-gen-go
in future then we'll do that in a central location and update all of the
.pb.go files at the same time, so that we're always consistently tracking
the same version of protocol buffers everywhere.
While doing this I attempted to keep as close as possible to the toolchain
we'd most recently used, but since they were not consistent with each
other they've now all changed which version numbers they record at minimum,
and the planproto stub in particular now also has a slightly different
descriptor serialization but is otherwise offering the same API.
The revision field is only populated on dev builds so this means
most releases of Terraform have an empty "terraform_revision" field
in the JSON output. Since we recommend developers use go tooling
to `go build` this tool when developing, the revision is not useful
data and so it is removed.
Remove chef, habitat, puppet, and salt-masterless provsioners,
which follows their deprecation. Update the documentatin for these
provisioners to clarify that they have been removed from later versions
of Terraform. Adds the fmt Make target back and updates fmtcheck script
for correctness.
