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

Terraform: Add experimental-deploy and wire-in dependency inference #19185

Merged
merged 22 commits into from Jun 25, 2023

Conversation

lilatomic
Copy link
Contributor

This was actually some prework for lockfiles. But Terraform has some ideas about differences between a "root" module (one you would deploy) and other modules (ones which would be included in a deployment). To model that, I creating the TerraformDeployment target type. Once you have that, might as well wire it in to the experimental-deploy goal (especially since that's most of the value of Terraform).
Also it looks like we weren't fetching dependencies (on other modules) when building up the files to run Terraform commands. Now that happens.

I feel like I'm not being efficient in this MR with the way I bundle the (pants-inferred) dependencies together with everything, since there's this ever-growing ball of files. LMK if we've got a better way.

@lilatomic lilatomic added backend: Terraform Terraform backend-related issues category:new feature labels May 29, 2023
@lilatomic
Copy link
Contributor Author

resolves #18491

@lilatomic
Copy link
Contributor Author

One complication is that this requires that the check goal is run against only terraform_deployment targets. This is technically in line with what Terraform tolerates, as it is possible for a "non-root" module to have incomplete provider blocks which would be specified in a root module (hashicorp/terraform#28490). OTOH, many non-root modules will not experience this, so maybe we should work around the need for a backend config. Is there a way to get a field only if it exists on the FieldSet?

@stuhood stuhood requested review from alonsodomin and tdyas May 30, 2023 22:09
Copy link
Contributor

@alonsodomin alonsodomin left a comment

Choose a reason for hiding this comment

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

A few nits here and there. It would be great if we could align this with other usages of the experimental-deploy so end users find some familiarity

src/python/pants/backend/terraform/target_types.py Outdated Show resolved Hide resolved
src/python/pants/backend/terraform/target_types.py Outdated Show resolved Hide resolved
src/python/pants/backend/terraform/target_types.py Outdated Show resolved Hide resolved
src/python/pants/backend/terraform/target_types.py Outdated Show resolved Hide resolved
src/python/pants/backend/terraform/tool.py Outdated Show resolved Hide resolved
description="Run `terraform init` to fetch dependencies",
chdir=directory,
),
)
Copy link
Contributor

Choose a reason for hiding this comment

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

This looks like a good candidate to be part of the generate-lockfiles goal

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I agree, I'm hoping to do that next.



@dataclass(frozen=True)
class GetTerraformDependenciesRequest:
Copy link
Contributor

Choose a reason for hiding this comment

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

Naming convention: In many backends, the more recent naming convention is FooRequest and FooResult. Although I see this code moved and I did not catch the naming issue before, :(

@Eric-Arellano: Thoughts here?



@dataclass(frozen=True)
class TerraformInitRequest:
Copy link
Contributor

Choose a reason for hiding this comment

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

Same comment re naming convention.

@lilatomic lilatomic marked this pull request as draft June 3, 2023 15:54
@lilatomic
Copy link
Contributor Author

wait, seems terraform_modules are deployable. I'm not sure that's desireable, or really why that's happening. Probably too loose a fieldset?

@lilatomic lilatomic marked this pull request as ready for review June 8, 2023 00:18
This is technically more correct, since `terraform validate` may not be valid on all modules
(since they don't have full provider blocks).
GetTerraformDependenciesRequest -> TerraformDependenciesRequest
TerraformDependencies -> TerraformDependenciesResponse
InitialisedTerraform -> TerraformInitResponse
@lilatomic
Copy link
Contributor Author

Dependency listing doesn't work yet, since the root_module field is just a string field. I'm planning to do what the golang backend did for the GoBinaryMainPackageField, which is to have a separate dependency inference for go_binary which adds that.

@alonsodomin
Copy link
Contributor

LGTM 👍

Comment on lines +121 to +122
address_input = request.root_module.to_address_input()
module_address = await Get(Address, AddressInput, address_input)
Copy link
Contributor

Choose a reason for hiding this comment

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

I would recommend inferring root_module to point at the terraform_module in the same directory if it is not specified. This is what go_binary does for the main field. (There should only be one terraform_module per directory so this inference should always work.)

Copy link
Contributor

Choose a reason for hiding this comment

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

But this is fine to be done as a follow-up.

@benjyw benjyw merged commit 2bfccd3 into pantsbuild:main Jun 25, 2023
24 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backend: Terraform Terraform backend-related issues category:new feature
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants