chore: updated Makefile and mmv builder

[wyardley]

• Chain the two go run commands in the mmv1 make target with && (edit: did a narrower fix here than in the initial PR)
  With this, the error in the linked ticket will now exit on provider build failure instead of continuing to the next step and exiting 0:

F1112 22:07:54.227629   53015 examples.go:300] template: artifact_registry_repository.go.tmpl:12: function "project" not defined
2024/11/12 22:07:54 products/dialogflowcx not specified, skipping generation
2024/11/12 22:07:54 products/iambeta not specified, skipping generation
2024/11/12 22:07:54 products/securitycenter not specified, skipping generation
2024/11/12 22:07:54 products/privateca not specified, skipping generation
exit status 1
make[1]: *** [mmv1] Error 1
make: *** [provider] Error 2
% echo $?
2

• Added the product being built in the case where forceProvider is set to an empty string, and changed prefix to "Building" vs "Using"

This avoids the extra space and missing provider type that show up when building the default (Terraform) provider:

2024/11/12 20:14:47 Using ga version
2024/11/12 20:14:47 Using  provider

in favor of:

2024/11/12 22:23:30 Building ga version
2024/11/12 22:23:30 Building default (terraform) provider

• Also fixed missing space here:

2024/11/12 22:40:26 Unexpected output folder (--version) detectedwhen deciding to add HashiCorp copyright headers.

Fixes hashicorp/terraform-provider-google#20317

Release Note Template for Downstream PRs (will be copied)

See Write release notes for guidance.

[github-actions]

Hello! I am a robot. Tests will require approval from a repository maintainer to run.

@slevenick, a repository maintainer, has been assigned to review your changes. If you have not received review feedback within 2 business days, please leave a comment on this PR asking them to take a look.

You can help make sure that review is quick by doing a self-review and by running impacted tests locally.

[slevenick]

Requesting review from @c2thorn who has more knowledge of this file than I do

[wyardley]

Requesting review from @c2thorn who has more knowledge of this file than I do

Thanks. Yeah, there may be some quirks, so for sure good to confirm that this will make things better and not worse. I'm happy to try and implement in a narrower way if there are concerns.

I uncovered some other weirdness with some of the targets (like clean-provider and some other targets not having a guard for OUTPUT_PATH being set, clean-provider being confused by vim swapfiles, etc.)

[c2thorn]

To be honest I'm not sure how I would verify that using SHELL here break some part of CI or break in somebody's developer environment that it was previously working in. I'm also having trouble finding documentation/references for it, and I haven't used it myself so I don't have previous experience with it personally. The risk to benefit ratio isn't looking worthwhile for me

Is there another way to do this only in bash?

[wyardley]

Only in bash, meaning fail on error only in the case where bash is available, or do you mean wrapping the build steps in the Make target with a bash script?

There could be some narrower fixes where we only adjust this specific target vs. setting SHELL for the makefile as a whole.

These two links have some information / possible ways to do it
https://stackoverflow.com/questions/23079651/equivalent-of-pipefail-in-gnu-make
https://stackoverflow.com/questions/33925523/how-to-set-pipefail-in-a-makefile

For that matter, both of the scripts in scripts/ are already bash specific (and in the case of scripts/doctor, hard-coded to /bin/bash vs using /usr/bin/env bash).

The risk to benefit ratio isn't looking worthwhile for me

I think the big risk here IMO is that someone doesn't notice a fatal build error and thinks it's succeeded. This could potentially cause evergreen builds in CI as well, if they're using the Makefile.

I would think that any modern system people are using for this should have at least some version of bash available somewhere, even if it's not in /bin. It is possible that some targets might need some adjustments later if a failing status somewhere causes issues, but I would guess most / all of these cases could be fixed.

I get what you're saying though -- happy to try for a narrower fix if you think that's better. Maybe it would work to do a && b instead of a ; b for the two go run commands in the mmv1 build target? In a quick test, that seems to work.

diff --git a/GNUmakefile b/GNUmakefile
index 118b5aabe..9307c6f1a 100644
--- a/GNUmakefile
+++ b/GNUmakefile
@@ -61,8 +61,7 @@ terraform build provider:
 mmv1:
 	cd mmv1;\
 		if [ "$(VERSION)" = "ga" ]; then \
-			go run . --output $(OUTPUT_PATH) --version ga --no-docs $(mmv1_compile); \
-			go run . --output $(OUTPUT_PATH) --version beta --no-code $(mmv1_compile); \
+			go run . --output $(OUTPUT_PATH) --version ga --no-docs $(mmv1_compile) && go run . --output $(OUTPUT_PATH) --version beta --no-code $(mmv1_compile); \
 		else \
 			go run . --output $(OUTPUT_PATH) --version $(VERSION) $(mmv1_compile); \
 		fi

While it of course isn't possible to test everyone's individual build environment, I do think there are two kinds of tests that could be done:

• Someone from Google / Hashicorp could run critical CI builds that don't run on PRs in a separate branch (by adjusting branch filters) to make sure they still function as expected
• You may be aware of the common build tasks developers run locally other than basic building of the provider, so could probably run through some of those tasks and make sure that they all work.

[wyardley]

@c2thorn see if you think the latest commit looks better / narrower. I also updated the PR description to match.