14 Commits (6dcf00aefc56b48bae54822a6e62eacffd2bc3ea)

Author	SHA1	Message	Date
Martin Atkins	4ec1feaa3d	build: CGO_ENABLED when building for macOS ... 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.	4 years ago
Martin Atkins	28a6036cf2	build: Separate Linux distro package builds into separate job ... 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.	4 years ago
Martin Atkins	c1699ea80c	build: Constrain permissions for the "build" workflow steps ... This workflow only generates artifacts and doesn't need to modify anything about the repository.	4 years ago
Martin Atkins	3bf758eaf5	build: Consolidate build-darwin job into just "build" ... 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.	4 years ago
Martin Atkins	218e55b23c	build: Build docs source package as part of the release pipeline ... 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.	4 years ago
Martin Atkins	b802db75d7	build: Build and run e2etest as part of the release build pipeline ... 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.	4 years ago
Martin Atkins	6704f8c795	Initial work on a new package build process ... 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.	4 years ago
Brian Flad	4b25a07bc7	Remove GitHub HashiBot configuration ... 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.	5 years ago
Alisdair McDiarmid	3ed08e3566	Remove backport review teams for now ... 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.	5 years ago
Alisdair McDiarmid	13d70844d7	Upgrade backport-assistant	5 years ago
Alisdair McDiarmid	61b38f3ada	Another action regex fix attempt ... This time I actually tested the regex	5 years ago
Alisdair McDiarmid	e65f427927	Try to fix backport action ... I made a mistake editing the regex. Here's hoping this works!	5 years ago
Alisdair McDiarmid	1e32354e3e	Fix label regexp ... We only use two components for versions, e.g. `0.13-backport` -> `v0.13`	5 years ago
Alisdair McDiarmid	fd14b237e5	Add backport assistant ... Based on documentation in https://github.com/hashicorp/backport-assistant, using a token from the teamterraform user.	5 years ago