This also sets an additional variable if it detects that this is an alpha
or development build, which currently does nothing but might eventually
turn on the ability to use experimental features, if we make that
something available only in prereleases.
The actions/checkout workflow does some heroics to try to fetch exactly
the commit being built and nothing else, even if asked to fetch the
history leading up to that commit. That means we don't end up having
enough information to get an accurate answer from "git describe".
Since we're intentionally relying on the git history here, we'll fetch
all of the tags explicitly after initial checkout. Although that does add
some delay to this step, we're intentionally doing this version
calculation only once as a separate workflow job so that all of the other
jobs can still benefit from this action's quicker checkout behavior.
The "push" event is only for pushes to branches within the same repository.
Since external contributors make commits in their own repositories rather than directly in the target repository, we also need the pull_request event to react to opening a pull request and to pushing new code to an external branch associated with a pull request.
Since internal pull requests would in principle trigger both "push" _and_ "pull_request", we also constrain the push event only to the branches we typically release from, on the assumption that all other branches will merge into those via pull requests. This avoids redundantly running the same checks in response to two events at the same time.
Building our protobuf files requires the protoc tool, which takes a little
while to download and install. Hopefully downloading it out of the GitHub
Actions cache will make it a little faster in the common case where we're
still using the same version as the previous run.
Originally we had this running as part of the Unit Tests job because most
of the checks are relatively fast. However, the addition of the protobuf
generation check made that no longer be true because it needs to download
and run protoc.
With that extra overhead it now _is_ productive to spend the time booting
and installing Go on third worker, as long as GitHub Actions continues
to let us run all three of these jobs concurrently most of the time.
goenv was making things more complicated than needed since it's really
designed to help with interactive use in a shell more than automated use
like this.
Instead, we'll follow the same strategy that our build.yml was doing of
just reading the .go-version file directly and then using the official
actions/setup-go action to do the actual installation. The key advantage
here is that Go ends up installed in a way where just running "go" will
do the right thing, and we no longer need to fuss with shims and
version-based path prefixes.
Rather than duplicating the logic from build.yml, instead it's factored
out into a separate composite action which both build.yml and checks.yml
will now share, in case we want to change the Go version selection
methodology in the future.
This factors out the "Install Go" step into a separate composite action
which we can then call from both of the jobs that need it.
We can't factor out the "Cache Go Modules" because GitHub doesn't allow
composite actions to refer to other external actions.
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.
Normally when we cross-compile we do so without CGo, because we don't have
suitable C headers available for systems other than the host.
However, building for macOS on macOS is special because there are
sufficient headers available on darwin_amd64 to build for both
darwin_amd64 _and_ darwin_arm64. Also, we _must_ use CGo on macOS because
the system resolver is only available via darwin's libc, and so building
without CGo produces executables that don't resolve hostnames correctly.
This is a conditional in bash to avoid having to duplicate the entire
step. Perhaps later we'll find a more general version of this which can
avoid the special case, but this is sufficient for the moment.
In our build workflow we'll treat Linux distribution packaging (currently
.deb and .rpm packages) as a separate job, instead of embedding it into
the "build" job, so that this step can happen concurrently with the other
derived actions like the docker image build, and the e2etest runs.
We can use an extra matrix dimension to select which execution environment
we'll use for each GOOS/GOARCH pair, and thus avoid duplicating the
job definition for darwin just to set runs-on: macos-latest for it.
This is not really an intended use of a matrix dimension because it's
directly related to the existing "goos" one, rather than being an
independent third dimension, but it doesn't matter in practice because
we're using the "include" option to specify exact combinations, and thus
we're not relying on the built-in functionality to generate all possible
matrix combinations.
This should eventually grow to be a step that actually verifies the
validity of the docs source prior to publishing the artifact that a
downstream publishing pipeline can consume, but for the moment it's really
just a placeholder since we have no such validation step and no downstream
pipeline consuming this artifact.
The general idea here is that the artifacts from this workflow should be
sufficient for all downstream release steps to occur without any direct
access to the Terraform CLI repository, and so this is intended to
eventually meet that ideal but as of this commit the website docs
publishing step _does_ still depend on direct access to this repository.
This uses the decoupled build and run strategy to run the e2etests so that
we can arrange to run the tests against the real release packages produced
elsewhere in this workflow, rather than ones generated just in time by
the test harness.
The modifications to make-archive.sh here make it more consistent with its
originally-intended purpose of producing a harness for testing "real"
release executables. Our earlier compromise of making it include its own
terraform executable came from a desire to use that script as part of
manual cross-platform testing when we weren't yet set up to support
automation of those tests as we're doing here. That does mean, however,
that the terraform-e2etest package content must be combined with content
from a terraform release package in order to produce a valid contest for
running the tests.
We use a single job to cross-compile the test harness for all of the
supported platforms, because that build is relatively fast and so not
worth the overhead of matrix build, but then use a matrix build to
actually run the tests so that we can run them in a worker matching the
target platform.
We currently have access only to amd64 (x64) runners in GitHub Actions
and so for the moment this process is limited only to the subset of our
supported platforms which use that architecture.
For the moment this is just an experimental additional sidecar package
build process, separate from the one we really use for releases, so that
we can get some experience building in the GitHub Actions environment
before hopefully eventually switching to using the artifacts from this
process as the packages we'll release through the official release
channels.
It will react to any push to one of our release branches or to a release
tag by building official-release-like .zip, .deb, and .rpm packages, along
with Docker images, based on the content of the corresponding commit.
For the moment this doesn't actually produce _shippable_ packages because
in particular it doesn't know how to update our version/version.go file
to hard-code the correct version number. Once Go 1.18 is release and we've
upgraded to it we'll switch to using debug.ReadBuildInfo to determine
our version number at runtime and so no longer need to directly update
a source file for each release, but that functionality isn't yet available
in our current Go 1.17 release.
Terraform is no longer going to silently capture all logs for a possible
crash report, and therefor won't create a crash.log file when a panic is
encountered.
The prompt to create a log file with TF_LOG from the Debug Output
section should suffice to get users to submit the logs when possible. In
the case of a crash specifically, the crash output also requests that
the stack trace be added to the issue for users who may not be aware of
what is necessary.
Change generic provider link to the registry, since the majority of
providers are no longer under the terraform-provider org.
Remove example link to an individual user's repo.
For the `closed_issue_locker` behavior, this is a migration to an equivalent action.
For the `label_issue_migrater` behavior, this is not replaced and instead it is suggested to use native GitHub functionality for issue transfer. If mostly equivalent behavior is desired via label automation, it may be possible to submit an issue transfer feature request to dessant/label-actions as it is a popular community action or create a new GitHub Action. Please reach out if this is a major issue for your team.
For the `remove_labels_on_reply` behavior, it is equivalent except this initial configuration does not make the collaborators distinction. There is a workflow configuration workaround for setting up per-user ignores for any job/step, so if you desire that here please reach out.
This requires more GitHub token permissions than we have, and it's
inessential. The backport PRs should have reviews assigned to the
original PR author anyway.
Add a written bug triage process and link to it in README.md
Bug process
Remove goals, edit for brevity, and move how to write a good issue report to bug report template
link HashiCorp GPG key in bug report template
add summary links for triage process
