Describe the Bug
This may also affect unaliased providers but I haven't dug into that as I didn't receive an error from tofu, while I did receive an error from tofu about aliased providers.
What's happening is that in my environment, we had versions.tf files with provider versions in some of our components, but not all, and we ran into an issue that our pipelines started taking longer and longer to run as we added more stacks and components into the workflow.
We can't (yet) parallelize the workflow but plan to, so in an effort to save some time I worked out a process to have all of the providers, required_version, and required_providers blocks defined in the atmos yaml, and a script parses that to pre-mirror the providers on each CI run and generate the lock files (we don't commit them to git for various reasons that I won't go into here, as I'm not familiar with them all.)
This works well, except for one small issue. For aliased providers in the yaml, when the yaml has a nested features: {} inside of the aliased azurerm provider definition, atmos is not creating the features block inside the provider block in the .tf file. This appears to be due to the features object in the yaml being empty; because when I add prevent_deletion_if_contains_resources: true (a provider default setting) to the yaml inside the features object, then it starts working properly.
Expected Behavior
I should be able to define features as an empty object in atmos yaml and have an empty features nested block created inside the azurerm provider block. This is a requirement of the azurerm provider that even if you are not setting anything within the block, you must still have the block present.
Steps to Reproduce
Define an azurerm provider in atmos providers yaml field, and a second aliased azurerm provider as well. Both can have an empty features object.
Then remove any providers that mention azurerm from the .tf manifests (you can leave required_providers and required_versions, as these are not involved in this bug.
Ensure that you have an empty aliased provider block defined in the .tf manifests to avoid a terraform error complaining about the code not containing base aliased provider block which is to be overridden.
Then run atmos terraform deploy for the component and stack and you should see terraform complain that the features block is missing from the provider block.
Screenshots
No response
Environment
No response
Additional Context
No response
Describe the Bug
This may also affect unaliased providers but I haven't dug into that as I didn't receive an error from tofu, while I did receive an error from tofu about aliased providers.
What's happening is that in my environment, we had versions.tf files with provider versions in some of our components, but not all, and we ran into an issue that our pipelines started taking longer and longer to run as we added more stacks and components into the workflow.
We can't (yet) parallelize the workflow but plan to, so in an effort to save some time I worked out a process to have all of the providers, required_version, and required_providers blocks defined in the atmos yaml, and a script parses that to pre-mirror the providers on each CI run and generate the lock files (we don't commit them to git for various reasons that I won't go into here, as I'm not familiar with them all.)
This works well, except for one small issue. For aliased providers in the yaml, when the yaml has a nested
features: {}inside of the aliased azurerm provider definition, atmos is not creating the features block inside the provider block in the .tf file. This appears to be due to the features object in the yaml being empty; because when I addprevent_deletion_if_contains_resources: true(a provider default setting) to the yaml inside the features object, then it starts working properly.Expected Behavior
I should be able to define features as an empty object in atmos yaml and have an empty features nested block created inside the azurerm provider block. This is a requirement of the azurerm provider that even if you are not setting anything within the block, you must still have the block present.
Steps to Reproduce
Define an azurerm provider in atmos
providersyaml field, and a second aliased azurerm provider as well. Both can have an empty features object.Then remove any providers that mention azurerm from the .tf manifests (you can leave required_providers and required_versions, as these are not involved in this bug.
Ensure that you have an empty aliased provider block defined in the .tf manifests to avoid a terraform error complaining about the code not containing base aliased provider block which is to be overridden.
Then run atmos terraform deploy for the component and stack and you should see terraform complain that the features block is missing from the provider block.
Screenshots
No response
Environment
No response
Additional Context
No response