bug: subscription_id is still required for az cli

[jaredfholgate]

Is there an existing issue for this?

• I have searched the existing issues

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave comments along the lines of "+1", "me too" or "any updates", they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment and review the contribution guide to help.

Terraform Version

latest

AzureRM Provider Version

latest

Affected Resource(s)/Data Source(s)

n/a

Terraform Configuration Files

terraform {
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~> 4.0"
    }
  }
}

provider "azurerm" {
  features {}
}

resource "azurerm_resource_group" "this" {
  name     = "rg-test"
  location = "UK South"
}

Debug Output/Panic Output

Planning failed. Terraform encountered an error while generating this plan.

╷
│ Error: building account: unable to configure ResourceManagerAccount: subscription ID could not be determined and was not specified
│ 
│   with provider["registry.terraform.io/hashicorp/azurerm"],
│   on main.tf line 10, in provider "azurerm":
│   10: provider "azurerm" {
│ 
╵

Expected Behaviour

The subscription id from az cli is used

Actual Behaviour

The plan fails

Steps to Reproduce

az login
terraform init
terraform plan

Important Factoids

No response

References

This PR was supposed to fix this, but it does not: #29985

Even when use_cli is explicitly set it still errors. I'm not sure how this fix was tested @jackofallops? Perhaps I am missing something?

This PR does not resolve the reported issue: #28627

[darose]

Any idea when this might get fixed? This bug is a big nuisance, as it's keeping us pinned to azurerm v3.0.*

[darose]

Is there any estimated release date/version for this issue?

[jaredfholgate]

Any idea when this might get fixed? This bug is a big nuisance, as it's keeping us pinned to azurerm v3.0.*

Why is this stopping you from upgrading to v4?

[darose]

Because I either need to modify all of our TF code to hard code in the subscription ID, or I need to script all of our TF code to set ARM_SUBSCRIPTION_ID on every TF plan/apply.

[jaredfholgate]

Because I either need to modify all of our TF code to hard code in the subscription ID, or I need to script all of our TF code to set ARM_SUBSCRIPTION_ID on every TF plan/apply.

Perhaps I am missing something, but aren't you setting the ARM_SUBSCRIPTION_ID env var already in your continuous delivery pipeline. You would only use Azure CLI in the local developer workflow. Developers can just run something like $env:ARM_SUBSCRIPTION_ID = $(az account show --query id -o tsv) when they need to test something locally.

Don't get me wrong, I know this issue is frustrating, but it shouldn't be a blocker for upgrading the provider version.

[darose]

There is no continuous delivery pipeline. The terraform code is executed locally/manually at the moment. So yes, if we want to use azurerm 4.x, then myself - and any other devs working on our projects - all need to either script our TF code to set ARM_SUBSCRIPTION_ID, or manually set it in our working environments. Can this be done? Yes. Is it a nuisance? Also yes. What I've been doing at the moment is staying pinned to azurerm 3.x, figuring that this issue would likely get fixed soon, so that we don't have to jump through those hoops to set ARM_SUBSCRIPTION_ID everywhere. (Which really shouldn't be needed.)

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.