You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Rename test folder and add nested e2e folder (ref)
Rename min folder to defaults
Rename common folder to max
Add waf-aligned folder (e.g., based on common). This test should not fail PSRule & show the module being deployed with best-practices
For each folder,
Update the serviceShort parameter to align with the new naming (e.g., waf for waf-aligned). For now, we should continue using min for defaults to align with PSRule.
Update the namePrefix input parameter value from [[namePrefix]] to #_namePrefix_# (the reason being that Bicep has a compilation issue because of the prefix & suffix in another location)
Remove the enableDefaultTelemetry parameter and reference in the test
Update the ../../main.bicep module template reference to ../../../main.bicep
If a resource group is deployed, update the RG parameter name to the new format that also uses the namePrefix. For example:
@description('Optional. The name of the resource group to deploy for testing purposes.')
@maxLength(90)
paramresourceGroupNamestring = 'dep-${namePrefix}-network.privateendpoints-${serviceShort}-rg'
(Optionally) add a block like the following below the target scope to render a more meaningful example in the ReadMe
metadataname = 'Using only defaults'metadatadescription = 'This instance deploys the module with the minimum set of required parameters.'
You should also try and test idempotency if possible. You can do this by updating the test invocation to
Add the roleAssignmentType described in the above reference to a // Definitions block at the bottom of the template file
Update the current roleAssignments parameter as per the specs (- should now reference the User-defined-type)
Take the current list of builtInRoleNames from the nested_roleAssignments.bicep file and add them to the variables block of the main template. The new schema does not require the nested template. Also, reduce the list of specified roles to only those that make sense for this resource (ref)/ For, for example, Cognitive Services, we should only provide the important ones as Owner, Contributor, etc. + all service specific roles such as 'Cognitive Services User'.
Replace the original module deployment block with the new resource deployment block
Check if any of the tests must be updated. The new block may look like
Add the privateEndpointType described in the above reference to a // Definitions block at the bottom of the template file
Update the current privateEndpoints parameter as per the specs (- should now reference the User-defined-type)
Updated the deployment block as per the specs to enable it to work with the new object type.
Note: For any resource that only supports one service/groupID (e.g. 'vault' for KeyVault, but NOT 'blob' for StorageAccount) we can provide a default value for that property (hence there are 2 variants in the spec).
Check if any of the tests must be updated. The new block may look like
privateEndpoints: [
{
privateDnsZoneResourceIds: [
nestedDependencies.outputs.privateDNSZoneResourceId
]
subnetResourceId: nestedDependencies.outputs.subnetResourceIdtags: {
'hidden-title': 'This is visible in the resource name'Environment: 'Non-Prod'Role: 'DeploymentValidation'
}
}
]
Add the customerManagedKeyType described in the above reference to a // Definitions block at the bottom of the template file
Remove any of the current customer-managed-key parameters & variables
Add the the new customerManagedKey parameter as per the specs to the template
Update the existing resource references as per the specs
Updated the deployment block as per the specs to enable it to work with the new object type
- ⚠️ BEWARE module-specific differences
- Note also that the new schema SHOULD support system-assigned-identities. As this cannot be done in a single deployment, you can find a reference how this would look like here
Check if any of the tests must be updated. The new block may look like
NOTE:⚠️ Make sure that if the module does not support e.g. metrics, that you update the logic accordingly
Other
Set version in version.json back to 0.1
(Optional) Introduce the new nullablefeature for parameters where-ever it makes sense to you (and ensure to test it). This enables us to simplify logic like in the following example
Regenerate all module ReadMe's & compile all module Bicep templates from the ground up. Ideally, remove the ReadMEs and regenerate them completely. Take note of any extra content (e.g., 'considerations') that were added manually and add them to the module's description metadata in the respective main.bicep file
To do
Checklist
Tests (ref)
e2efolder (ref)minfolder todefaultscommonfolder tomaxwaf-alignedfolder (e.g., based oncommon). This test should not fail PSRule & show the module being deployed with best-practicesserviceShortparameter to align with the new naming (e.g.,wafforwaf-aligned). For now, we should continue usingminfordefaultsto align with PSRule.namePrefixinput parameter value from[[namePrefix]]to#_namePrefix_#(the reason being that Bicep has a compilation issue because of the prefix & suffix in another location)enableDefaultTelemetryparameter and reference in the test../../main.bicepmodule template reference to../../../main.bicepnamePrefix. For example:For each module that supports
Diagnostic Settings
diagnosticSettingTypedescribed in the above reference to a// Definitionsblock at the bottom of the template filediagnosticSettingsparameter as per the specs to the templateRole Assignments
roleAssignmentTypedescribed in the above reference to a// Definitionsblock at the bottom of the template fileroleAssignmentsparameter as per the specs (- should now reference the User-defined-type)builtInRoleNamesfrom thenested_roleAssignments.bicepfile and add them to the variables block of the main template. The new schema does not require the nested template. Also, reduce the list of specified roles to only those that make sense for this resource (ref)/ For, for example, Cognitive Services, we should only provide the important ones as Owner, Contributor, etc. + all service specific roles such as 'Cognitive Services User'.Resource Locks
lockTypedescribed in the above reference to a// Definitionsblock at the bottom of the template filelockparameter as per the specs (- should now reference the User-defined-type)Tags
tagsparameter as per the specsManaged Identities
managedIdentitiesTypedescribed in the above reference to a// Definitionsblock at the bottom of the template filemanagedIdentitiesparameter as per the specs to the templatePrivate Endpoints
privateEndpointTypedescribed in the above reference to a// Definitionsblock at the bottom of the template fileprivateEndpointsparameter as per the specs (- should now reference the User-defined-type)Customer Managed Keys
customerManagedKeyTypedescribed in the above reference to a// Definitionsblock at the bottom of the template filecustomerManagedKeyparameter as per the specs to the templateexistingresource references as per the specs-
- Note also that the new schema SHOULD support system-assigned-identities. As this cannot be done in a single deployment, you can find a reference how this would look like here
Other
version.jsonback to0.1nullablefeature for parameters where-ever it makes sense to you (and ensure to test it). This enables us to simplify logic like in the following exampleReadMe
main.bicepfile