-
Notifications
You must be signed in to change notification settings - Fork 442
Known issues
This section provides an overview of the most impactful limitations and known issues. We are actively working on tracking them as GitHub issues and resolving them.
This section outlines known issues that currently affect the modules.
The Domain Services module pipeline is expected to fail in our development/validation environment for a few reasons:
- The leveraged service principal doesn't have the required permissions to actually deploy the service in the used tenant.
- The referenced (optional)
pfxCertificateand password don't actually exist in the specified Key Vault - unless uploaded manually.
Therefore, the module was manually tested in a dedicated environment.
For the general prerequisites, please refer to the official docs.
The Management Group module does not currently include the role assignments extension resource.
Including RBAC capabilities has been tested setting the scope to the previously created management group and resulted in failing already in the validation step with the error: 'ManagementGroupNotFound - The management group 'EXAMPLEMG' cannot be found'.
A related issue has been opened to the Bicep board #6832.
Further details are also provided in issue #1342.
The Recovery Services Vaults module does not currently validate the identity property (system or user assigned identity).
The module pipeline fails in the deployment validation step when system and user assigned identity parameters are added as input parameters.
A related issue has been opened in the Bug board #2391.
There is currently an issue when deploying a network manager instance for a management group scope where the management group ID is a guid. For example, if the management group resource ID looks like /providers/Microsoft.Management/managementGroups/f2857922-1732-4c0d-a8d4-7003b13be520, then this will fail when the deployment happens via code but succeed if it was created using the Azure Portal. This does not impact management group IDs that use a regular string such as mg-contoso.
The workaround is to deploy network manager using the Azure Portal first, before triggering it via code. This has been communicated to the network manager team and waiting on investigation outcomes and the documentation will be updated accordingly.
A related issue has been opened in the Bug board #2551 to keep track of the network manager issue.
This section outlines known issues that currently affect the CI environment, i.e., the validation and publishing pipelines.
This section outlines known issues that currently affect the CI environment static validation step, i.e., Pester tests.
This section outlines known issues that currently affect the CI environment deployment validation step.
The deployment validation step aims to validate multiple configurations for each module. This is done by providing multiple module test files to be leveraged by the same resource module, each covering a specific scenario.
The first planned step for each module is to provide a 'minimum-set' module test file, limited to the top-level resource required parameters, vs. a 'maximum-set' module test file, including all possible properties, child resources and extension resources. Some of the modules are still tested through one module test file only. This is tracked by issue #401.
GitHub workflows used to validate CARML modules are running on GitHub-hosted runners.
In such a scenario, as documented in the Usage limits for GitHub Actions workflows, if a job reaches a limit of 6 hours of execution time, the job is terminated and fails to complete.
For modules that can take more than 6 hours to deploy, this restriction applies. In these cases, the corresponding deployment validation job may be terminated before completion, causing the entire module validation pipeline to fail. One module where this can happen is the Microsoft.Sql\managedInstances module.
This section outlines known issues that currently affect the CI environment publishing step.