Malte S. Stretz
Malte S. Stretz
Potential problem to consider: What about mixins which are vendored (as directories, not single files) into non-vendored directories? Maybe #488 would be required to make that safe. For example: I...
> > Potential problem to consider: What about mixins which are vendored (as directories, not single files) into non-vendored directories? Maybe #488 would be required to make that safe. >...
Hmmm... not sure. Maybe for others, probably not in my use case since we have `components/terraform` in `.gitignore` so the vendored directories are technically not in git but for develoment...
@osterman thanks for the quick reply, I didn't expect it to be acted upon quickly, just wanted to note our interest. Maybe we'll find time to implement it, since @astephanh...
Just using the `default` workspace (via `TF_WORKSPACE=default`) doesn't work, results in the error `Failed to unlock state: failed to retrieve lock info for lock ID "8ac7bbfc-c1b4-615d-38d7-f7ba634aa4bb": unexpected end of JSON...
This doesn't work either: ```bash TF_WORKSPACE=default atmos terraform shell wms-base --stack wms-xe02-sandbox unset TF_WORKSPACE terraform workspace new -lock=false wms-xe02-sandbox-wms-base terraform force-unlock 8ac7bbfc-c1b4-615d-38d7-f7ba634aa4bb ``` The `terraform workspace new` fails already. Looks...
I think this is at least partially broken on the Terraform side, cf. linked ticket.
@RoseSecurity I think that makes sense. It should probably default to hiding disabled components. Unfortunately was the referenced change #828 stalled; it included a lot of not really related stuff...
Note to myself: Check if this was implemented in v1.201.0 via #1812.
I think the proper title for this issue would be "`default` function doesn't work anymore with partial context". We also ran into this issue with a file which looks like...