Skip to content
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

Merged
merged 6 commits into from
Apr 3, 2024

Conversation

bdwyertech
Copy link
Contributor

@bdwyertech bdwyertech commented Feb 6, 2023

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:

  • Run make reviewable to ensure this PR is ready for review.

How has this code been tested

@Upbound-CLA
Copy link

Upbound-CLA commented Feb 6, 2023

CLA assistant check
All committers have signed the CLA.

Copy link
Collaborator

@bobh66 bobh66 left a 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/ ?

internal/terraform/terraform.go Show resolved Hide resolved
package/crds/tf.upbound.io_workspaces.yaml Outdated Show resolved Hide resolved
package/crds/tf.upbound.io_workspaces.yaml Outdated Show resolved Hide resolved
@bdwyertech
Copy link
Contributor Author

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

@bobh66
Copy link
Collaborator

bobh66 commented Feb 8, 2023

@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.

@bdwyertech
Copy link
Contributor Author

OK, I can break that out separately, however this is a prereq to use tfenv.

@bobh66
Copy link
Collaborator

bobh66 commented Feb 8, 2023

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!

@bdwyertech
Copy link
Contributor Author

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!

OK, I've broken tfenv into its branch and will create a subsequent PR. For now, this is MR just adds env var support.

@bdwyertech
Copy link
Contributor Author

Added support for ConfigMap/Secret reference.

@bdwyertech bdwyertech force-pushed the env-support branch 2 times, most recently from 6e33ddd to fb24ab0 Compare February 9, 2023 19:20
@nakamume
Copy link
Contributor

nakamume commented Mar 6, 2023

@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.

@addisonj
Copy link

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.

@bobh66
Copy link
Collaborator

bobh66 commented May 24, 2023

Is this ready for another review? Is there anything else preventing this from making progress?

There are lint errors blocking the CI pipeline

Comment on lines 177 to 191
cmd.Env = append(cmd.Env, "TF_CLI_CONFIG_FILE=./.terraformrc")
cmd.Env = append(cmd.Env, h.Envs...)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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...)

Copy link
Contributor Author

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)

@ytsarev
Copy link
Member

ytsarev commented May 25, 2023

/test-examples="examples/workspace-inline-aws.yaml"

@bdwyertech bdwyertech force-pushed the env-support branch 2 times, most recently from 7778b57 to a739694 Compare May 25, 2023 01:48
@addisonj
Copy link

@bobh66 it looks like all requested changes have been made?

@rrs-celonis
Copy link

Eagerly waiting for this to get merged

@ytsarev
Copy link
Member

ytsarev commented Aug 11, 2023

/test-examples="examples/workspace-inline-aws.yaml"

1 similar comment
@ytsarev
Copy link
Member

ytsarev commented Aug 28, 2023

/test-examples="examples/workspace-inline-aws.yaml"

@ytsarev
Copy link
Member

ytsarev commented Aug 29, 2023

/test-examples="examples/workspace-inline-aws.yaml"

@senare
Copy link

senare commented Oct 13, 2023

Any update on this ?
What can I do t to help this move along ?

@ytsarev
Copy link
Member

ytsarev commented Oct 17, 2023

@senare Ideally we need to

@ytsarev
Copy link
Member

ytsarev commented Apr 3, 2024

/test-examples="examples/workspace-inline-aws.yaml"

Signed-off-by: Yury Tsarev <yury@upbound.io>
Signed-off-by: Yury Tsarev <yury@upbound.io>
Copy link
Member

@ytsarev ytsarev left a 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
image

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!

Copy link
Collaborator

@bobh66 bobh66 left a 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'
Copy link
Collaborator

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?

Copy link
Member

@ytsarev ytsarev Apr 3, 2024

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

README.md Show resolved Hide resolved
description = "Environment Value From Secret"
type = string
}
env:
Copy link
Collaborator

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree, example amended

@@ -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...)
Copy link
Collaborator

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?

Copy link
Member

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

Copy link
Contributor Author

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>
@ytsarev ytsarev requested a review from bobh66 April 3, 2024 22:16
@ytsarev
Copy link
Member

ytsarev commented Apr 3, 2024

@bobh66 thanks a lot for the review. I've addressed the PR feedback. Please take another look

Copy link
Collaborator

@bobh66 bobh66 left a 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 !

@ytsarev ytsarev merged commit 51dda57 into upbound:main Apr 3, 2024
9 checks passed
@bdwyertech
Copy link
Contributor Author

Better late than never... Thanks guys, I can finally stop using my fork :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

9 participants