'Global' as location triggers "Replace this hardcoded location with a parameter."

  • What language is this for: Bicep
  • Which rule: azureresourcemanager:S6949
  • Why do you believe it’s a false-positive:
    Azure Action Group is a global service and it should be allowed to hardcode the location to ‘Global’.
  • Are you using: SonarCloud
  • How can we reproduce the problem:
    Main.bicep:
resource actionGroup 'Microsoft.Insights/actionGroups@2019-06-01' = {
  name: 'Action Group'
  location: 'Global'
  properties: {
    groupShortName: 'Web App'
    enabled: true
    emailReceivers: [
      {
        emailAddress: 'test@test.com'
        name: 'Support email'
        useCommonAlertSchema: true
      }
    ]
  }
}

Hello @vedion, thanks for the report!

Indeed, this looks like a false positive. I created a ticket to fix it in the analyzer. You can track the progress here: [SONARIAC-1491] - Jira

Best,

Peter

I see that this was fixed in SONARIAC-1491 S6949 should not raise for "Global" location by GabinL21 · Pull Request #1517 · SonarSource/sonar-iac · GitHub and the fix was released in Release 1.35.0.12330 · SonarSource/sonar-iac · GitHub – but only for lower-case “global”. If the location is “Global”, it still violates the rule. This is even described in the unit tests, so it is clearly the intended behavior. However, what is the rationale for that behavior, @peter.trifanov?

E.g., in Azure Portal, the export of an Azure CDN profile resource contains “Global” with capital G. I am not sure if location names are case-insensitive in general (cannot find an authoritative answer), but I guess so. I just know that while “West Europe” is a canonical location name, “westeurope” (lower-case, without the space) is also accepted and works correctly.

Hello @TomasMalecek!

Thanks for pointing this out. Locations in Azure RM have separate fields for name and displayName, and apparently both can be accepted as location values. For the global location, capitalized Global is a display name, while just global is a name.

I wasn’t aware that ARM accepts both forms. You are right, we should raise in neither of cases. I’ve created a ticket to adjust the rule’s behavior here.

Best,

Peter

1 Like