Pull request #246 breaks the pipeline execution

[ghost]

Describe the bug We are using management group scoped service connection for AzureRM provider and were able to successfully use this extension by explicitly defining the provider subscription ID in a provider configuration. After #246 has been released, we started getting error message because we do not have providerAzureRmSubscriptionId explicitly defined in our pipeline configuration. Our problem is that we do not expect breaking changes in extension to be applied within the existing task version (in our case TerraformCLI@0), so the suggestion is to release such changes as a new task version. Let me highlight that we are not able to control extension upgrades within AzureDevOps, so such things really break our stuff.

To Reproduce Steps to reproduce the behavior:

1. Have a pipeline without explicit providerAzureRmSubscriptionId for plan or apply commands.
2. Have a provider subscription defined in a provider configuration explicitly.
3. Have a version of extension 0.7.0 installed
4. Have a management group scoped service connection used to initialize terraform.

Expected behavior The above scenario should continue to work as with 0.7.4 version considering the old TerraformCLI@0 task usage. New behavior should be released in new task version.

Screenshots Pipeline Logs Include logs that help demonstrate the problem. Please make sure to redact any sensitive info such as secrets.

Agent Configuration

• OS: ubuntu-20.04
• Self Hosted
• Terraform version used 1.1.2
• NA

• Additional context NA

[charleszipp]

Thanks for reporting this issue. I will get a release to make this field optional. Apologies for the unintended breaking change. I was not aware there were management group service connections already being used.

Quick question, is the subscription id being set in this case as an environment variable and/or within the terraform template itself? I would like to understand how its being configured outside the task inputs.

[ghost]

Thanks for reporting this issue. I will get a release to make this field optional. Apologies for the unintended breaking change. I was not aware there were management group service connections already being used.

Quick question, is the subscription id being set in this case as an environment variable and/or within the terraform template itself? I would like to understand how its being configured outside the task inputs.

Thanks for quick response. We were able to work around the issue by passing a placeholder value (any non-empty string) to the providerAzureRmSubscriptionId. In our configuration we set a subscription ID explicitly in provider configuration block (TF code) and it was working fine with management group scoped service connection. Making this attribute optional is actually a good idea because it allows the user to decide what is best way of treating provider configuration in particular case. I would say it was possible to use management group scoped service connection even with init commands with TerraformCLI@0. We were able to pass it using additional CLI argument, so it was another unnecessary breaking change introduced in 0.7.4.

Based on TF docs, provider configuration allows explicit subscription ID definitions which take precedence over the env var. Moreover, if the config presumes provider aliases, it becomes completely unnecessary to provide subscription id as a part of service connection or set is as env var at all.

We (myself and the whole team I am working with) would really appreciate if you could introduce breaking changes in a newer task versions going forward (like TerraformCLI@1). We really value the benefits of your extension over competitors, so it makes us sad when we get unexpected behavior.

[charleszipp]

@orest-lavriv-1001 this was released with 0.7.6. Can you confirm this resolved the issue for you?