[AVM Module Issue]: res/web/site not appending EndpointSuffix to AzureWebJobsStorage

[sindkor]

Check for previous/existing GitHub issues

• [X] I have checked for previous/existing GitHub issues

Issue Type?

Bug

Module Name

avm/res/web/site

(Optional) Module Version

0.3.7

Description

Using the following module call:

module function 'br/public:avm/res/web/site:0.3.7' = {
  name: '${functionName}-deployment'

  dependsOn: [
    storage
  ]

  params: {
    name: functionName
    location: location

    kind: 'functionapp,linux'
    serverFarmResourceId: asp.outputs.resourceId
    appInsightResourceId: appInsights.outputs.resourceId
    storageAccountResourceId: storage.outputs.resourceId

    managedIdentities: {
      systemAssigned: true
    }

    siteConfig: {
      alwaysOn: false
    }

    appSettingsKeyValuePairs: {
      FUNCTIONS_EXTENSION_VERSION: '~4'
      FUNCTIONS_WORKER_RUNTIME: 'java'
      AZURE_FUNCTIONS_ENVIRONMENT: environmentName == 'prod' ? 'Production' : 'Development'
      FUNCTION_APP_EDIT_MODE: 'readonly'
      WEBSITE_CONTENTAZUREFILECONNECTIONSTRING: storageAccountConnectionString
      WEBSITE_CONTENTSHARE: functionName
    }
  }
}

I've set Java version 17 and OS as Linux in pom.xml.

The module sets the app setting/environment variable AzureWebJobsStorage as expected. However, it does not append EndpointSuffix=core.windows.net. This leads to the following error when trying to deploy to the function using the Github Action Azure/functions-action:

Error: Invalid EndpointSuffix in the provided Connection String
    at extractConnectionStringParts (/home/runner/work/_actions/Azure/functions-action/v1/node_modules/@azure/storage-blob/dist/index.js:13685:23)
    at BlobServiceClient.fromConnectionString (/home/runner/work/_actions/Azure/functions-action/v1/node_modules/@azure/storage-blob/dist/index.js:24336:32)
    at WebsiteRunFromPackageDeploy.<anonymous> (/home/runner/work/_actions/Azure/functions-action/v1/lib/publishers/websiteRunFromPackageDeploy.js:27:70)
    at Generator.next (<anonymous>)
    at /home/runner/work/_actions/Azure/functions-action/v1/lib/publishers/websiteRunFromPackageDeploy.js:8:71
    at new Promise (<anonymous>)
    at __awaiter (/home/runner/work/_actions/Azure/functions-action/v1/lib/publishers/websiteRunFromPackageDeploy.js:4:12)
    at WebsiteRunFromPackageDeploy.execute (/home/runner/work/_actions/Azure/functions-action/v1/lib/publishers/websiteRunFromPackageDeploy.js:23:16)
    at ContentPublisher.<anonymous> (/home/runner/work/_actions/Azure/functions-action/v1/lib/handlers/contentPublisher.js:25:68)
    at Generator.next (<anonymous>)

If I manually append EndpointSuffix=core.windows.net to AzureWebJobsStorage in the Azure Portal deployment works fine.

(Optional) Correlation Id

No response

[microsoft-github-policy-service[bot]]

[!IMPORTANT] The "Needs: Triage :mag:" label must be removed once the triage process is complete!

[!TIP] For additional guidance on how to triage this issue/PR, see the BRM Issue Triage documentation.

[avm-team-linter[bot]]

@sindkor, thanks for submitting this issue for the avm/res/web/site module!

[!IMPORTANT] A member of the @Azure/avm-res-web-site-module-owners-bicep or @Azure/avm-res-web-site-module-contributors-bicep team will review it soon!

[sindkor]

A workaround seems to be to set the AzureWebJobsStorage-parameter directory in appSettingsKeyValuePairs and unset storageAccountResourceId.

var storageAccountConnectionString = 'DefaultEndpointsProtocol=https;AccountName=${storage.outputs.name};AccountKey=${listKeys(resourceId('Microsoft.Storage/storageAccounts', storageAccountName), '2023-01-01').keys[0].value};EndpointSuffix=${environment().suffixes.storage}'

(...)

AzureWebJobsStorage: storageAccountConnectionString

This might not work if you're configuring slots, as it also seems to use the storageAccountResourceId-parameter. Additionally, there might also be issues if the storage account doesn't already exists when the listKeys()-function is ran.

[microsoft-github-policy-service[bot]]

[!WARNING] Tagging the AVM Core Team (@Azure/avm-core-team-technical-bicep) due to a module owner or contributor having not responded to this issue within 3 business days. The AVM Core Team will attempt to contact the module owners/contributors directly.

[!TIP]

• To prevent further actions to take effect, the "Status: Response Overdue 🚩" label must be removed, once this issue has been responded to.
• To avoid this rule being (re)triggered, the ""Needs: Triage :mag:" label must be removed as part of the triage process (when the issue is first responded to)!

[microsoft-github-policy-service[bot]]

[!WARNING] Tagging the AVM Core Team (@Azure/avm-core-team-technical-bicep) due to a module owner or contributor having not responded to this issue within 3 business days. The AVM Core Team will attempt to contact the module owners/contributors directly.

[!TIP]

• To prevent further actions to take effect, the "Status: Response Overdue 🚩" label must be removed, once this issue has been responded to.
• To avoid this rule being (re)triggered, the ""Needs: Triage :mag:" label must be removed as part of the triage process (when the issue is first responded to)!

[microsoft-github-policy-service[bot]]

[!CAUTION] This issue requires the AVM Core Team's (@Azure/avm-core-team-technical-bicep) immediate attention as it hasn't been responded to within 6 business days.

[!TIP]

• To avoid this rule being (re)triggered, the "Needs: Triage :mag:" and "Status: Response Overdue :triangular_flag_on_post:" labels must be removed when the issue is first responded to!
• Remove the "Needs: Immediate Attention :bangbang:" label once the issue has been responded to.

[tsc-buddy]

Hi There - Thanks for logging this issue. We shall triage this wc 8th July.