It is helpful to see the result of the checks workflow prior to opening
a PR, to avoid wasting time fixing unexpectedly failing checks while the
PR is open and awaiting review. This commit configures GitHub Actions to
run checks on all pushed branches.
* 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
Currently, discussions are not a feature we use on GitHub. However, we did not want to enable an automated behavior that would be difficult and confusing to track down for a future enabler of GitHub Discussions.
* add new actions for executing the equivalence tests after a CRT release
* ready for review
* Update .github/actions/equivalence-test/action.yml
Co-authored-by: CJ Horton <17039873+radditude@users.noreply.github.com>
* address comments
---------
Co-authored-by: CJ Horton <17039873+radditude@users.noreply.github.com>
* Migrate set-output to GITHUB_OUTPUT
Signed-off-by: Scott Macfarlane <smacfarlane@hashicorp.com>
* Migrate terraform to CRT
* Update ci branches & ci notification channel
* Use version/VERSION file to parse version
* Remove fetch raw version script and update pipeline to run on current branch
* PR feedback: cgo-enabled now required flag, updated comments & include promotion steps in ci.hcl
* Update version for main
---------
Signed-off-by: Scott Macfarlane <smacfarlane@hashicorp.com>
Co-authored-by: Scott Macfarlane <smacfarlane@hashicorp.com>
Co-authored-by: emilymianeil <eneil@hashicorp.com>
* add some basic equivalence tests and execute them in the build pipeline
* remove old file, now unused
* update terraform-equivalence-testing to v0.2.0
* add separate action
* make sure to read from hashicorp repo
* remove elevated github token where possible
* Don't need elevated token anymore
* update with official mock provider
* last change: don't need the authorization header for public repositories.
The importscheck script now uses "go run" to run this program and so
the Go toolchain will install it automatically using the version number
of golang.org/x/tools specified in our go.mod file.
* 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 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.
