upstream/terraform
1
0
Fork 0
mirror of https://github.com/hashicorp/terraform.git synced 2026-02-03 20:50:59 -05:00
Code Issues Projects Releases Packages Wiki Activity Actions 3
terraform/Makefile

48 lines
1.3 KiB
Makefile
Raw Normal View History

Comment Makefile
2015-01-26 21:19:22 -05:00
# generate runs `go generate` to build the dynamically generated
build: Take protoc out of the "go generate" path Since protoc is not go-gettable, and most development tasks in Terraform won't involve recompiling protoc files anyway, we'll use a separate mechanism for these. This way "go generate" only depends on things we can "go get" in the "make tools" target. In a later commit we should also in some way specify a particular version of protoc to use so that we don't get "flapping" regenerations as developers work with different versions, but the priority here is just to make "make generate" minimally usable again to restore the dev workflow documented in the README. This also includes some updates that resulted from running "make generate" and "make protobuf" after those Makefile changes were in place.
2018-10-18 12:27:48 -04:00
# source files, except the protobuf stubs which are built instead with
# "make protobuf".
Version tools per Go convention under tools.go
2019-10-17 16:17:23 -04:00
generate:
remove vendor from some tooling
2020-09-23 16:57:36 -04:00
go generate ./...
helper/schema: generate strings for ValueType
2015-01-10 18:51:53 -05:00
build: Take protoc out of the "go generate" path Since protoc is not go-gettable, and most development tasks in Terraform won't involve recompiling protoc files anyway, we'll use a separate mechanism for these. This way "go generate" only depends on things we can "go get" in the "make tools" target. In a later commit we should also in some way specify a particular version of protoc to use so that we don't get "flapping" regenerations as developers work with different versions, but the priority here is just to make "make generate" minimally usable again to restore the dev workflow documented in the README. This also includes some updates that resulted from running "make generate" and "make protobuf" after those Makefile changes were in place.
2018-10-18 12:27:48 -04:00
# We separate the protobuf generation because most development tasks on
# Terraform do not involve changing protobuf files and protoc is not a
# go-gettable dependency and so getting it installed can be inconvenient.
#
build: Centralize our protobuf compilation steps 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.
2021-08-20 19:07:18 -04:00
# If you are working on changes to protobuf interfaces, run this Makefile
# target to be sure to regenerate all of the protobuf stubs using the expected
# versions of protoc and the protoc Go plugins.
build: Take protoc out of the "go generate" path Since protoc is not go-gettable, and most development tasks in Terraform won't involve recompiling protoc files anyway, we'll use a separate mechanism for these. This way "go generate" only depends on things we can "go get" in the "make tools" target. In a later commit we should also in some way specify a particular version of protoc to use so that we don't get "flapping" regenerations as developers work with different versions, but the priority here is just to make "make generate" minimally usable again to restore the dev workflow documented in the README. This also includes some updates that resulted from running "make generate" and "make protobuf" after those Makefile changes were in place.
2018-10-18 12:27:48 -04:00
protobuf:
build: Centralize our protobuf compilation steps 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.
2021-08-20 19:07:18 -04:00
go run ./tools/protobuf-compile .
build: Take protoc out of the "go generate" path Since protoc is not go-gettable, and most development tasks in Terraform won't involve recompiling protoc files anyway, we'll use a separate mechanism for these. This way "go generate" only depends on things we can "go get" in the "make tools" target. In a later commit we should also in some way specify a particular version of protoc to use so that we don't get "flapping" regenerations as developers work with different versions, but the priority here is just to make "make generate" minimally usable again to restore the dev workflow documented in the README. This also includes some updates that resulted from running "make generate" and "make protobuf" after those Makefile changes were in place.
2018-10-18 12:27:48 -04:00
Make gofmt errors fail build and add `make fmt` We may want to consider requiring `gofmt -s` compliance in future builds, but for now we just use `gofmt`.
2015-12-17 12:21:43 -05:00
fmtcheck:
build: Run scripts directly from makefile, rather than via sh All four of these scripts have #! lines calling for them to run in bash, and they are all marked as executable, so there's no harm in running them directly and it makes it clearer that we're running them in the shell specified on the #! line, rather than with whatever "sh' happens to be on the current system. (Note that this _was_ still correctly using the #! lines before, because it's `sh -c` rather than just `sh`, but nonetheless that old way seemed needlessly confusing.)
2022-08-25 18:49:39 -04:00
"$(CURDIR)/scripts/gofmtcheck.sh"
Make gofmt errors fail build and add `make fmt` We may want to consider requiring `gofmt -s` compliance in future builds, but for now we just use `gofmt`.
2015-12-17 12:21:43 -05:00
Add goimports as a check to the Github commit actions (#31432) * 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
2022-07-19 05:14:28 -04:00
importscheck:
build: Run scripts directly from makefile, rather than via sh All four of these scripts have #! lines calling for them to run in bash, and they are all marked as executable, so there's no harm in running them directly and it makes it clearer that we're running them in the shell specified on the #! line, rather than with whatever "sh' happens to be on the current system. (Note that this _was_ still correctly using the #! lines before, because it's `sh -c` rather than just `sh`, but nonetheless that old way seemed needlessly confusing.)
2022-08-25 18:49:39 -04:00
"$(CURDIR)/scripts/goimportscheck.sh"
Add goimports as a check to the Github commit actions (#31432) * 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
2022-07-19 05:14:28 -04:00
Add go vet as a check to the Github commit actions (#31461) * Add go vet as a check to the Github commit actions * deliberately break to test * fix after successful test * Use directly * fix more errors
2024-11-07 11:29:58 -05:00
vetcheck:
@echo "==> Checking that the code complies with go vet requirements"
@go vet ./...
add staticcheck make target cleanup the old fmtcheck script while we're in here
2020-12-02 12:02:33 -05:00
staticcheck:
build: Run scripts directly from makefile, rather than via sh All four of these scripts have #! lines calling for them to run in bash, and they are all marked as executable, so there's no harm in running them directly and it makes it clearer that we're running them in the shell specified on the #! line, rather than with whatever "sh' happens to be on the current system. (Note that this _was_ still correctly using the #! lines before, because it's `sh -c` rather than just `sh`, but nonetheless that old way seemed needlessly confusing.)
2022-08-25 18:49:39 -04:00
"$(CURDIR)/scripts/staticcheck.sh"
add staticcheck make target cleanup the old fmtcheck script while we're in here
2020-12-02 12:02:33 -05:00
build: Add exhaustive switch statement lint 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.
2021-09-24 15:02:30 -04:00
exhaustive:
build: Run scripts directly from makefile, rather than via sh All four of these scripts have #! lines calling for them to run in bash, and they are all marked as executable, so there's no harm in running them directly and it makes it clearer that we're running them in the shell specified on the #! line, rather than with whatever "sh' happens to be on the current system. (Note that this _was_ still correctly using the #! lines before, because it's `sh -c` rather than just `sh`, but nonetheless that old way seemed needlessly confusing.)
2022-08-25 18:49:39 -04:00
"$(CURDIR)/scripts/exhaustive.sh"
build: Add exhaustive switch statement lint 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.
2021-09-24 15:02:30 -04:00
ci: Add test for license headers (#34624) * 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
2024-02-14 02:53:39 -05:00
copyright:
"$(CURDIR)/scripts/copyright.sh" --plan
copyrightfix:
"$(CURDIR)/scripts/copyright.sh"
go.mod: Separate modules at code ownership boundaries 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.
2024-03-08 19:05:48 -05:00
syncdeps:
"$(CURDIR)/scripts/syncdeps.sh"
Disallow parallelism in Makefile
2017-02-17 18:31:20 -05:00
# disallow any parallelism (-j) for Make. This is necessary since some
# commands during the build process create temporary files that collide
# under parallel conditions.
.NOTPARALLEL:
website: (Re)Move markdown documentation (#37417) * website: (Re)Move markdown documentation * make: remove website targets * gitignore: remove website paths * CODEOWNERS: remove website paths * gh/ISSUE_TEMPLATE: Direct folks to unified repo for docs * Readme: Update link to docs * Update refs to website folder * Re-add Readme.md with a warning and link to the unified repo
2025-08-11 05:25:18 -04:00
.PHONY: fmtcheck importscheck vetcheck generate protobuf staticcheck syncdeps
Reference in a new issue Copy permalink