-
Notifications
You must be signed in to change notification settings - Fork 59
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
Add support for setting env variables in a workspace #74
Conversation
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.
Thanks for the contribution! Looks good overall, a couple of comments inline. Can you also add some documentation in the README and maybe an example in examples/ ?
Sure, I'll fix the tests and get an example into the README |
@bdwyertech I'm concerned that this is now two features in one PR - the original ENV support and the addition of tfenv. I'd prefer to keep them separate - the tfenv change is much more significant and I'd like to be able to validate it separately. |
OK, I can break that out separately, however this is a prereq to use tfenv. |
Thanks - I think the env var support is fine, and could even be extended to support valueFrom and secrets at some point. That would enable credentials to be loaded into the environment from a Secret, which I know some terraform providers might need. Can you open an issue with some more background/details for the tfenv support? It would be good to get some specifics and discussion around the topic. It's a significant change to support multiple versions of terraform. Thanks! |
c4e7c6a
to
0d96b42
Compare
OK, I've broken tfenv into its branch and will create a subsequent PR. For now, this is MR just adds env var support. |
0d96b42
to
b01aecc
Compare
Added support for ConfigMap/Secret reference. |
6e33ddd
to
fb24ab0
Compare
@bobh66 @bdwyertech Though not a blocker but this feature would greatly improve our workflows. I'd like continue with these changes. I guess, I'll have to fork and open a new PR. Please let me know if there's some way to contribute to this same PR. |
It looks like some the changes were split out and the requested changes were made. Is this ready for another review? Is there anything else preventing this from making progress? This would be super useful to me and would be happy to help contribute, but just need clear direction from the maintainers (@bobh66) on what is missing to get this over the line. |
There are lint errors blocking the CI pipeline |
internal/terraform/terraform.go
Outdated
cmd.Env = append(cmd.Env, "TF_CLI_CONFIG_FILE=./.terraformrc") | ||
cmd.Env = append(cmd.Env, h.Envs...) |
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.
cmd.Env = append(cmd.Env, "TF_CLI_CONFIG_FILE=./.terraformrc") | |
cmd.Env = append(cmd.Env, h.Envs...) | |
cmd.Env = append(cmd.Env, "TF_CLI_CONFIG_FILE=./.terraformrc", h.Envs...) |
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.
You cant do that.
21:47:07 [ .. ] go build linux_amd64
github.com/upbound/provider-terraform/apis/v1beta1
github.com/upbound/provider-terraform/internal/terraform
# github.com/upbound/provider-terraform/internal/terraform
internal/terraform/terraform.go:177:65: too many arguments in call to append
have ([]string, string, []string)
want ([]string, ...string)
/test-examples="examples/workspace-inline-aws.yaml" |
7778b57
to
a739694
Compare
@bobh66 it looks like all requested changes have been made? |
Eagerly waiting for this to get merged |
/test-examples="examples/workspace-inline-aws.yaml" |
1 similar comment
/test-examples="examples/workspace-inline-aws.yaml" |
/test-examples="examples/workspace-inline-aws.yaml" |
Any update on this ? |
@senare Ideally we need to
|
(cherry picked from commit 2acfe08)
/test-examples="examples/workspace-inline-aws.yaml" |
Signed-off-by: Yury Tsarev <yury@upbound.io>
Signed-off-by: Yury Tsarev <yury@upbound.io>
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.
- I've rebased this PR with the recent state of the
main
branch and resolved some conflicts - Added e2e example to
examples/environment
to test environment propagation - Performed exploratory e2e test, everything works as expected
k get workspace
NAME SYNCED READY AGE
sample-inline-with-env True True 19m
- The environment data was properly propagated to the AWS tags as expected
Everything looks good to me.
@bobh66 As I've made additions to this PR could you please make another review from your side before we merge it? Thanks!
@bdwyertech thank you so much for this great contribution!
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.
A couple of minor comments and one question, but otherwise it LGTM.
README.md
Outdated
# Environment variables can be passed through | ||
env: | ||
- name: TFENV_TERRAFORM_VERSION | ||
value: '1.3.5' |
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.
Will this be confusing since you can't really change the version of terraform that we run?
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.
I've renamed the env var to a more neutral version
description = "Environment Value From Secret" | ||
type = string | ||
} | ||
env: |
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.
nit: I think it flows better to have the env
definition before the module
definition, but it's not critical to change
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.
Agree, example amended
internal/terraform/terraform.go
Outdated
@@ -185,6 +188,7 @@ func (h Harness) Init(ctx context.Context, o ...InitOption) error { | |||
cmd.Env = append(cmd.Env, e) | |||
} | |||
cmd.Env = append(cmd.Env, "TF_CLI_CONFIG_FILE=./.terraformrc") | |||
cmd.Env = append(cmd.Env, h.Envs...) |
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.
This line appends h.Envs...
unconditionally, where all of the other usages check the length and only append if the length is non-zero. Is there a reason to check the length in the other places and not check it here? Or does it not need to be checked at all?
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.
Good catch, it is probably harmless from the way how append behaves, but let's make it cleaner, I've added the conditional
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.
So just for solidarity, the reason I did not add the check here was because the line above already appended. My reasoning behind checking in the other cases was because I'd rather inherit the default behavior of cmd.Env. If you notice, I pick up os.Environ()
which is the default if you do not set cmd.Env. Should the Go upstream behavior change or whatever, my goal was to avoid interfering... if that makes sense. That said, there is no harm here in adding the check, probably some picosecond of compute or something.
Signed-off-by: Yury Tsarev <yury@upbound.io>
@bobh66 thanks a lot for the review. I've addressed the PR feedback. Please take another look |
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.
Looks good - thanks @bdwyertech and @ytsarev !
Better late than never... Thanks guys, I can finally stop using my fork :-) |
Description of your changes
Goal of this was to pass through env vars for TFEnv. This would allow me to pin or constrain Terraform versions in my versioned XRs. Perhaps it could be used for something else, such as specifying the terraform source, or provider-specific debug flags.
I have:
make reviewable
to ensure this PR is ready for review.How has this code been tested