Apply now fails with a 400 complaining about the provider being set:
# azurerm_static_site.frontend will be updated in-place
~ resource "azurerm_static_site" "frontend" {
id = "/subscriptions/REDACTED/resourceGroups/REDACTED/providers/Microsoft.Web/staticSites/REDACTED"
name = "REDACTED"
~ tags = {
+ "foo2" = "bar"
# (5 unchanged elements hidden)
}
# (6 unchanged attributes hidden)
}
azurerm_static_site.frontend: Modifying... [id=/subscriptions/REDACTED/resourceGroups/REDACTED/providers/Microsoft.Web/staticSites/REDACTED]
│ Error: failed creating Static Site: (Name "REDACTED" / Resource Group "REDACTED"): web.StaticSitesClient#CreateOrUpdateStaticSite: Failure sending request: StatusCode=400 -- Original Error: Code="BadRequest" Message="Provider is invalid. Cannot change the Provider. Please detach your static site first if you wish to use to another deployment provider." Details=[{"Message":"Provider is invalid. Cannot change the Provider. Please detach your static site first if you wish to use to another deployment provider."},{"Code":"BadRequest"},{"ErrorEntity":{"Code":"BadRequest","ExtendedCode":"51021","Message":"Provider is invalid. Cannot change the Provider. Please detach your static site first if you wish to use to another deployment provider.","MessageTemplate":"{0} is invalid. {1}","Parameters":["Provider","Cannot change the Provider. Please detach your static site first if you wish to use to another deployment provider."]}}]
Debug Output
The SWA details from the azure CLI, note that provider is set to DevOps:
The azurerm provider is able to update the SWA resource successfully without forcing the user to detach their static site.
I'm unsure how this should be fixed, as the SWA provider is not tracked in the terraform state (see above). I'm thinking the azurerm provider could retrieve and echo all the properties object in its update request. In this case, care should be taken when a TF SWA resource attribute would set a property field; e.g. the provider could do a merge of the properties object in this case. Alternatively, perhaps dropping the empty properties: {} object from the PUT request might be a feasible workaround.
From this issue I understand that not only the provider might have to be set, but maybe also properties related to the provider (for the DevOps this appears to be branch and repositoryUrl).
Community Note
Terraform (and AzureRM Provider) Version
Affected Resource(s)
azurerm_static_site
Terraform Configuration Files
Create the static site with the following configuration:
After deploying the SWA, publish a site to the SWA. E.g. from Azure devops.
Finally, update the TF config for the SWA, e.g. by adding a new tag:
Apply now fails with a 400 complaining about the provider being set:
Debug Output
The SWA details from the azure CLI, note that provider is set to DevOps:
The terraform state of the SWA:
The offending request sent to azurerm and its response (TF_LOG=DEBUG):
Expected Behaviour
The azurerm provider is able to update the SWA resource successfully without forcing the user to detach their static site.
I'm unsure how this should be fixed, as the SWA provider is not tracked in the terraform state (see above). I'm thinking the azurerm provider could retrieve and echo all the properties object in its update request. In this case, care should be taken when a TF SWA resource attribute would set a property field; e.g. the provider could do a merge of the properties object in this case. Alternatively, perhaps dropping the empty
properties: {}
object from the PUT request might be a feasible workaround.edit: see the properties property in the response for get-static-site: https://docs.microsoft.com/en-us/rest/api/appservice/static-sites/get-static-site. The response is as follows for the SWA in this issue:
Actual Behaviour
Updating the SWA resource fails.
Steps to Reproduce
terraform apply
terraform apply
againImportant Factoids
References
From this issue I understand that not only the provider might have to be set, but maybe also properties related to the provider (for the DevOps this appears to be branch and repositoryUrl).