When we run many of these together e.g. in the checks.yaml GitHub Actions
workflow, it's hard to tell from the output exactly which command is
producing which subset of the output.
To help clarify that, we'll ask make to print out the command line it's
running before it runs it.
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.
This is a complement to "timestamp" and "timeadd" which allows
establishing the ordering of two different timestamps while taking into
account their timezone offsets, which isn't otherwise possible using the
existing primitives in the Terraform language.
This fixes a possible panic in what Terraform calls the "flatten" function
in situations where a user passes in a null value of a sequence type.
The function will now treat that the same as a null value of any other
type.
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.
Go 1.19's "fmt" has some awareness of the new doc comment formatting
conventions and adjusts the presentation of the source comments to make
it clearer how godoc would interpret them. Therefore this commit includes
various updates made by "go fmt" to acheve that.
In line with our usual convention that we make stylistic/grammar/spelling
tweaks typically only when we're "in the area" changing something else
anyway, I also took this opportunity to review most of the comments that
this updated to see if there were any other opportunities to improve them.
Prevously the cloud backend would only render post-plan run tasks. Now
that pre-plan tasks are in beta, this commit updates the plan phase to
render pre-plan run tasks. This commit also moves some common code to
the common backend as it will be used by other task stages in the
future.
The goal of this change is to simplify the process of filing
issues with hashicorp/terraform. In the previous Markdown syntax,
the instructions tended to get washed out in a sea of comment
markers. The new Github Form Issues breaks each section into a form
element, with instructions printed clearly as HTML in the page.
We are further hoping to guide users to the correct repository when
filing provider issues, or the community forums when asking usage
questions.
Previously we didn't describe the interaction between default values and
callers explicitly passing "null".
We treat an explicit null as the same as omitting the attribute when
applying defaults, because that then allows callers to use the typical
pattern for conditional assignment, using explicit null as a fallback
to the module's defined default without having to duplicate that default:
example = var.foo ? "hello" : null
