-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore: updated Makefile and mmv builder #12314
chore: updated Makefile and mmv builder #12314
Conversation
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. |
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 |
GNUmakefile
Outdated
@@ -1,3 +1,5 @@ | |||
SHELL=/usr/bin/env bash -eo pipefail |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@c2thorn see if you think the latest commit looks better / narrower. I also updated the PR description to match.
e2c156c
to
7dbc99d
Compare
@slevenick This PR has been waiting for review for 3 weekdays. Please take a look! Use the label |
@GoogleCloudPlatform/terraform-team @slevenick This PR has been waiting for review for 1 week. Please take a look! Use the label |
Removed myself from review as I don't have much context on the new build files |
@GoogleCloudPlatform/terraform-team @slevenick This PR has been waiting for review for 2 weeks. Please take a look! Use the label |
@c2thorn any thoughts about the updated version? |
@GoogleCloudPlatform/terraform-team @slevenick This PR has been waiting for review for 3 weeks. Please take a look! Use the label |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Apologies, I was OOO. @wyardley this seems like a viable alternative, thank you. I'll run the build.
/gcbrun |
Thanks! I suggested a similar solution in #12341, which I think would have had a similar problem. |
Build will not run on the branch since it affects the makefile. I will test this offline and probably merge tomorrow just so it won't collide with the release today. Setting a calendar reminder to do so |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
getting the following on my machine when testing
camthornton-mac:magic-modules camthornton$ make mmv1 VERSION=ga OUTPUT_PATH="$GOPATH/src/github.com/hashicorp/terraform-provider-google"
cd mmv1;\
if [ "ga" = "ga" ]; then \
# Chaining these with "&&" is critical here to prevent this
/bin/sh: -c: line 1: syntax error: unexpected end of file
make: *** [mmv1] Error 2
Removing the comments fixes this. Or we can move them above the cd mmv1;\
line, I think folks would be able to understand the lines it is referring to
Weird, maybe I didn’t test again after adding the comments, or some slight difference in our setup. Yes, I can make that change and will test again locally as well. |
4bf3e01
to
df7244b
Compare
Thanks for testing again. Verified the issue, updated the comment, and tested build again locally. |
@slevenick This PR has been waiting for review for 3 weekdays. Please take a look! Use the label |
@GoogleCloudPlatform/terraform-team @slevenick This PR has been waiting for review for 1 week. Please take a look! Use the label |
Hi @c2thorn just bugging you here since I think the automatic ones are still bugging Sam instead. |
@GoogleCloudPlatform/terraform-team @slevenick This PR has been waiting for review for 2 weeks. Please take a look! Use the label |
@GoogleCloudPlatform/terraform-team @slevenick This PR has been waiting for review for 3 weeks. Please take a look! Use the label |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Got around to testing this, and it seems to be working now. Thanks @wyardley
go run
commands in themmv1
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:
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:
in favor of:
Fixes hashicorp/terraform-provider-google#20317
Release Note Template for Downstream PRs (will be copied)
See Write release notes for guidance.