feat(provisioner/terraform/tfparse): implement WorkspaceTagDefaultsFromFile #15236
Conversation
There was a problem hiding this comment.
I focused on high level of this solution.
What I like here:
- we're trying to construct the build context first and use it as a source of truth for
ParseExpression - There is a potential of introducing a "super parser" that can natively guess (support) placeholder values for provisioner tags
Open questions:
- how does it work when
coder_parameterdoes not have a default value? maybe I missed it in code - is there any risk of breaking the build context if a template author pushes another template version with renamed parameters or variables?
- when exactly this solution does not work?
I'm happy to discuss this solution in 1-1. I think you're on the right path but we may need to patch some loopholes.
|
Thanks for all the comments! I'm going to take a pass now and address them. |
9214bd4 to
3db3e6b
Compare
| } | ||
|
|
||
| if _, ok := resContent.Attributes["default"]; !ok { | ||
| defaultsM[dataResource.Name] = "" |
There was a problem hiding this comment.
Should we specify if the default is "" or actually not present?
This would make a tag "" if no default is provided. Should we error instead? Is that a breaking change if we error?
There was a problem hiding this comment.
That's a good point. The whole reason for doing this is to make sure that we have some default defined for the workspace_tags data source. So it probably should be an error.
There was a problem hiding this comment.
Upon closer inspection, this is only for parsing coder_parameters. It is legit to have an empty default value for a coder_parameter. We do not want to block this behaviour.
However, when using that coder_parameter as a transitive source for a coder_workspace_tags value, we want to ensure that that tag is set. This is checked in WorkspaceTagDefaults and has its own corresponding unit test.
| // parseHCLFiler is the actual interface of *hclparse.Parser we use | ||
| // to parse HCL. This is extracted to an interface so we can more | ||
| // easily swap this out for an alternative implementation later on. | ||
| type parseHCLFiler interface { |
There was a problem hiding this comment.
I know :D I'm just following the Go convention of <function name>er.
…#15578) Relates to #15087 and #15427 - Extracts provisioner job tags from `coder_workspace_tags` on template version creation using `provisioner/terraform/tfparse` added in #15236 - Drops a WARN log in coderd if no matching provisioners found. - Also drops a warning message in the CLI if no provisioners are found. - To support both CLI and UI warnings, added a `codersdk.MatchedProvisioners` struct to the `TemplateVersion` response containing details of how many provisioners were around at the time of the insert. Co-authored-by: Mathias Fredriksson <[email protected]>
Relates to #15087 and #15427
Adds functionality to
provisioner/terraform/tfparseto extract the default values for acoder_workspace_tagsdata source from a given file.A subsequent PR will hook this into the template creation flow.
Update: I've since found that Trivy uses its own Terraform parser to perform static analysis.
This will allow us to support things like function calls in future.
For now, I'm keeping our existing approach but I would like to leverage this package in future.