feat: Add diagnostics parameter

[SanderNugteren]

Description

I added the diagnostics parameter for Log Analytics. However, I was unable to fully test the changes due to issues with the local setup. I would appreciate it if someone with a working environment could verify and complete the testing.

Fixes #3519
-->

Pipeline Reference

Pipeline

Type of Change

• Update to CI Environment or utilities (Non-module affecting changes)
• Azure Verified Module updates:
  • Bugfix containing backwards-compatible bug fixes, and I have NOT bumped the MAJOR or MINOR version in version.json:
    • Someone has opened a bug report issue, and I have included "Closes #{bug_report_issue_number}" in the PR description.
    • The bug was found by the module author, and no one has opened an issue to report it yet.
  • Feature update backwards compatible feature updates, and I have bumped the MINOR version in version.json.
  • Breaking changes and I have bumped the MAJOR version in version.json.
  • Update to documentation

Checklist

• I'm sure there are no other open Pull Requests for the same update/change
• I have run Set-AVMModule locally to generate the supporting module files.
• My corresponding pipelines / checks run clean and green without any errors or warnings

[SanderNugteren]

@SanderNugteren please read the following Contributor License Agreement(CLA). If you agree with the CLA, please reply with the following information.

@microsoft-github-policy-service agree [company="{your company}"]

Options:

• (default - no company specified) I have sole ownership of intellectual property rights to my Submissions and I am not making Submissions in the course of work for my employer.

@microsoft-github-policy-service agree

• (when company given) I am making Submissions in the course of work for my employer (or my employer has intellectual property rights in my Submissions by contract or applicable law). I have permission from my employer to make Submissions and enter into this Agreement on behalf of my employer. By signing below, the defined term “You” includes me and my employer.

@microsoft-github-policy-service agree company="Microsoft"

Contributor License Agreement

@microsoft-github-policy-service agree company="Waternet"

[AlexanderSehr]

Hey @SanderNugteren,
happy to do so by rebasing your PR (which keeps you as the author) and testing it in my environment. However, before doing so, I'd need to ask you to merge the latest upstream AVM version into your fork and resolve the conflicts. It appears your version of the module is missing some updates that were already implemented in the upstream repository.
Just make sure your actions are disabled before pulling the changes into your fork as this may result in all of them being triggered (if not disabled).

[SanderNugteren]

Hi @AlexanderSehr! I resolved the conflicts. Thanks for the help in getting this merged!

[JPEasier]

Thank you very much for your contribution!
I see some conflicts, please review and update your branch.

[AlexanderSehr]

I wonder if we shold make both these values optional if the resourceId is provided. If the case, we can fetch both values via an existing resource reference on behalf of the user, making this a lot easier to use

[AlexanderSehr]

This would by the way look something like this

@description('Optional. The log analytics diagnostic information for a container group.')
param logAnalytics logAnalyticsType?

resource law 'Microsoft.OperationalInsights/workspaces@2025-02-01' existing = if (!empty(logAnalytics.?workspaceResourceId)) {
  name: last(split(logAnalytics.?workspaceResourceId!, '/'))
  scope: resourceGroup(
    split(logAnalytics.?workspaceResourceId!, '/')[2],
    split(logAnalytics.?workspaceResourceId!, '/')[4]
  )
}

resource containergroup 'Microsoft.ContainerInstance/containerGroups@2023-05-01' = {
  (...)
    diagnostics: !empty(logAnalytics)
      ? {
          logAnalytics: {
            logType: logAnalytics!.logType
            workspaceId: logAnalytics!.?workspaceId ?? (!empty(logAnalytics.?workspaceResourceId)
              ? law.properties.customerId
              : fail('Either the workspaceId or the workspaceResourceId must be provided.'))
            #disable-next-line use-secure-value-for-secure-inputs // False-positive - Is declared as secure()
            workspaceKey: logAnalytics!.?workspaceKey ?? (!empty(logAnalytics.?workspaceResourceId)
              ? law.listKeys().primarySharedKey
              : fail('Either the workspaceKey or the workspaceResourceId must be provided.'))
            #disable-next-line use-secure-value-for-secure-inputs // Not a secret
            workspaceResourceId: logAnalytics!.?workspaceResourceId
            metadata: logAnalytics!.?metadata
          }
        }
      : null
  (...)
}

@export()
@description('The type for the log analytics diagnostics.')
type logAnalyticsType = {
  @description('Required. The log type to be used.')
  logType: ('ContainerInsights' | 'ContainerInstanceLogs')

  @description('Conditional. The workspace ID for log analytics. Required if `workspaceResourceId` is not provided.')
  workspaceId: string?

  @description('Conditional. The workspace key for log analytics. Required if `workspaceResourceId` is not provided.')
  @secure()
  workspaceKey: string?

  @description('Conditional. The workspace resource id for log analytics. Required if `workspaceId` or `workspaceId` is not provided.')
  workspaceResourceId: string?

  @description('Optional. Metadata for log analytics.')
  metadata: object?
}

allowing you to populate the parameter like

      logAnalytics: {
        logType: 'ContainerInsights'
        workspaceResourceId: nestedDependencies.outputs.logAnalyticsWorkspaceResourceId
      }

[SanderNugteren]

Thanks for the example! I was trying to implement your suggestion on my own but didn't think about using the fail function to enforce either (workspaceId and workspaceKey) or (workspaceResourceId) to be set, so I kept getting warnings.

[AlexanderSehr]

Glad to hear. In that case there'd only be one ask at least from my side (@JPEasier may have more as the owner) and that is to expand on the modules tests/e2e/max/main.bicep test case by adding an LAW deployment to its dependencies.bicep file and the parameter to the deployment on the bottom of the file main.test.bicep, referecing e.g. the LAW resource ID output of the dependencies.bicep file (once added). Note: If you do that, you'll have to run the Set-AVMModule script again as the deployment will be addded to the readme's 'Usage Examples'.
Finally, you ideally run the test case in your fork using the module's workflow (assuming you have set it up), or at least using the Test-ModuleLocally script with some indicator that the test worked. We have to ensure it does before merging the change in.

[SanderNugteren]

Hi @AlexanderSehr ! Thanks again for all the help yesterday! I will have a look at this tomorrow!

[AlexanderSehr]

Thank you. @JPEasier, please resolve this comment once addressed as I'll be out of office for the next 2.5 weeks