diff --git a/.github/workflows/platform.linkcheck.yml b/.github/workflows/platform.linkcheck.yml new file mode 100644 index 0000000000..e134d292d6 --- /dev/null +++ b/.github/workflows/platform.linkcheck.yml @@ -0,0 +1,33 @@ +name: '.Platform: Broken Links Check' + +on: + workflow_dispatch: + pull_request: + branches: + - main + paths: + - 'docs/wiki/**' + +jobs: + build: + name: Broken Links Check + runs-on: ubuntu-latest + steps: + - name: Checkout Code + uses: actions/checkout@v2 + with: + # Full git history is needed to get a proper list of changed files within `super-linter` + fetch-depth: 0 + + - name: Check Broken Links + if: always() + id: checker + uses: lycheeverse/lychee-action@v1.1.1 + with: + args: --verbose --no-progress **/docs/**/*.md --accept 200,201,403,429 + env: + GITHUB_TOKEN: ${{secrets.GITHUB_TOKEN}} + + - name: Publish Results + if: always() + run: exit ${{ steps.checker.outputs.exit_code }} diff --git a/arm/Microsoft.Compute/virtualMachineScaleSets/readme.md b/arm/Microsoft.Compute/virtualMachineScaleSets/readme.md index 4f1e419349..691dc568e6 100644 --- a/arm/Microsoft.Compute/virtualMachineScaleSets/readme.md +++ b/arm/Microsoft.Compute/virtualMachineScaleSets/readme.md @@ -197,25 +197,16 @@ The following resources are required to be able to deploy this resource. ```json -"extensionDomainJoinConfig": { - "value": { - "settings": { - "Name": ".onmicrosoft.com", - "User": "domainJoinUser02@.onmicrosoft.com", - "OUPath": "OU=Template-Test; DC=; DC=onmicrosoft; DC=com", - "Restart": true, - "Options": "" - } - } -} -``` - -Should be configured alongside: -```json -"extensionDomainJoinPassword": { - "reference": { - "keyVault": { - "id": "/subscriptions/<>/resourceGroups/validation-rg/providers/Microsoft.KeyVault/vaults/" +"windowsScriptExtensionFileData": { + "value": [ + //storage accounts with SAS token requirement + { + "uri": "https://mystorageAccount.blob.core.windows.net/avdscripts/File1.ps1", + "storageAccountId": "/subscriptions/12345678-1234-1234-1234-123456789012/resourceGroups/rgName/providers/Microsoft.Storage/storageAccounts/storageAccountName" + }, + { + "uri": "https://mystorageAccount.blob.core.windows.net/avdscripts/File2.ps1", + "storageAccountId": "/subscriptions/12345678-1234-1234-1234-123456789012/resourceGroups/rgName/providers/Microsoft.Storage/storageAccounts/storageAccountName" }, "secretName": "domainJoinUser-Password" } diff --git a/arm/Microsoft.Compute/virtualMachines/readme.md b/arm/Microsoft.Compute/virtualMachines/readme.md index 125f6fd3dd..5b2abb2edf 100644 --- a/arm/Microsoft.Compute/virtualMachines/readme.md +++ b/arm/Microsoft.Compute/virtualMachines/readme.md @@ -343,9 +343,9 @@ Only for OSType Windows "diskEncryptionSettings": { "value": { "EncryptionOperation": "EnableEncryption", - "KeyVaultURL": "https://adp-sxx-az-kv-x-001.vault.azure.net/", + "KeyVaultURL": "https://mykeyvault.vault.azure.net/", "KeyVaultResourceId": "/subscriptions/<>/resourceGroups/validation-rg/providers/Microsoft.KeyVault/vaults/adp-sxx-az-kv-x-001", - "KeyEncryptionKeyURL": "https://adp-sxx-az-kv-x-001.vault.azure.net/keys/keyEncryptionKey/685153483a1140e3856f004a753e1ab4", + "KeyEncryptionKeyURL": "https://mykeyvault.vault.azure.net/keys/keyEncryptionKey/685153483a1140e3856f004a753e1ab4", "KekVaultResourceId": "/subscriptions/<>/resourceGroups/validation-rg/providers/Microsoft.KeyVault/vaults/adp-sxx-az-kv-x-001", "KeyEncryptionAlgorithm": "RSA-OAEP", //'RSA-OAEP'/'RSA-OAEP-256'/'RSA1_5' "VolumeType": "All", //'OS'/'Data'/'All' @@ -409,11 +409,11 @@ Only for OSType Windows "value": [ //storage accounts with SAS token requirement { - "uri": "https://storageAccount.blob.core.windows.net/avdscripts/File1.ps1", + "uri": "https://mystorageaccount.blob.core.windows.net/avdscripts/File1.ps1", "storageAccountId": "/subscriptions/12345678-1234-1234-1234-123456789012/resourceGroups/rgName/providers/Microsoft.Storage/storageAccounts/storageAccountName" }, { - "uri": "https://storageAccount.blob.core.windows.net/avdscripts/File2.ps1", + "uri": "https://mystorageaccount.blob.core.windows.net/avdscripts/File2.ps1", "storageAccountId": "/subscriptions/12345678-1234-1234-1234-123456789012/resourceGroups/rgName/providers/Microsoft.Storage/storageAccounts/storageAccountName" }, //storage account with public container (no SAS token is required) OR other public URL (not a storage account) diff --git a/arm/Microsoft.ContainerService/managedClusters/agentPools/readme.md b/arm/Microsoft.ContainerService/managedClusters/agentPools/readme.md index 929311fc88..fa853264e1 100644 --- a/arm/Microsoft.ContainerService/managedClusters/agentPools/readme.md +++ b/arm/Microsoft.ContainerService/managedClusters/agentPools/readme.md @@ -48,7 +48,7 @@ For available properties check -As we want to enable any user of this repository's content to not only leverage its modules but actually also re-use the platform, the platform itself is set up so that you can plug it into your own environment with just a few basic steps described in the [Getting Started](./GettingStarted) section. You may choose to add or remove modules, define your own locations you want to publish to and as such create your own open- or inner-source library. +As we want to enable any user of this repository's content to not only leverage its modules but actually also re-use the platform, the platform itself is set up so that you can plug it into your own environment with just a few basic steps described in the [Getting Started](./GettingStarted.md) section. You may choose to add or remove modules, define your own locations you want to publish to and as such create your own open- or inner-source library. diff --git a/docs/wiki/ContributionGuide.md b/docs/wiki/ContributionGuide.md index b54a1600d2..e21b366657 100644 --- a/docs/wiki/ContributionGuide.md +++ b/docs/wiki/ContributionGuide.md @@ -13,13 +13,13 @@ This section outlines how you can contribute to the repository. # Set your environment up -The preferred method of contribution requires you to create your own fork and create pull requests into the source repository from there. To set the fork up, please follow the process described in the ['Getting Started'](./GettingStarted#Option-1-Use-it-as-a-basis-to-set-up-your-own-inner-source-project) section. +The preferred method of contribution requires you to create your own fork and create pull requests into the source repository from there. To set the fork up, please follow the process described in the ['Getting Started'](./GettingStarted.md#Option-1-Use-it-as-a-basis-to-set-up-your-own-inner-source-project) section. # How to contribute? You can contribute to the Wiki in different ways depending on your own interests, bugs you see or IP you want to add. -For starters it is highly recommended to consult and understand the ['Modules Design'](./ModulesDesign) section of the wiki. +For starters it is highly recommended to consult and understand the ['Modules Design'](./ModulesDesign.md) section of the wiki. How you proceed from here depends on your particular situation: @@ -36,4 +36,4 @@ To contribute to the modules, set your environment up, test the updated/added mo Status Badge -Please make sure to set your environment up and also consult the ['Pipeline Design'](./PipelinesDesign) and ['Pipeline Usage'](.\PipelinesUsage) sections. +Please make sure to set your environment up and also consult the ['Pipeline Design'](./PipelinesDesign.md) and ['Pipeline Usage'](./PipelinesUsage.md) sections. diff --git a/docs/wiki/GettingStarted.md b/docs/wiki/GettingStarted.md index 36e3896863..e6f9d89b43 100644 --- a/docs/wiki/GettingStarted.md +++ b/docs/wiki/GettingStarted.md @@ -117,7 +117,7 @@ Please refer to [this list][AzureNames] to check which services have a global sc ### Dependencies -As the modules we test often times have dependencies to other services, we created a pipeline to deploys several standard services like VirtualNetworks and KeyVaults (alongside dummy secrets) for the modules to use. This _dependency_ pipeline should be prepared and executed before you start running any pipelines on your own. In case you need to rename any services there (for example because a certain globally unique resource name was already taken) make sure to update any references to this name in the module parameter files. You can find further details about this pipeline [here](.\TestingDesign#Module-Dependencies). +As the modules we test often times have dependencies to other services, we created a pipeline to deploys several standard services like VirtualNetworks and KeyVaults (alongside dummy secrets) for the modules to use. This _dependency_ pipeline should be prepared and executed before you start running any pipelines on your own. In case you need to rename any services there (for example because a certain globally unique resource name was already taken) make sure to update any references to this name in the module parameter files. You can find further details about this pipeline [here](./TestingDesign.md#Module-Dependencies). ### GitHub-specific prerequisites @@ -173,7 +173,7 @@ In case you would like to simply contribute because you, for example, want to ad ## Parameter File Tokens -If you are forking or cloning the repository, you can use 'tokens' inside your parameter files. Tokens allow you to test deploying modules in your own environment (i.e. using tokens for your naming conventions), or apply other customizations to your resources (i.e. using your own subscription ID inside a Resource ID string). See details in the [Parameter File Tokens Design](./ParameterFileTokens). +If you are forking or cloning the repository, you can use 'tokens' inside your parameter files. Tokens allow you to test deploying modules in your own environment (i.e. using tokens for your naming conventions), or apply other customizations to your resources (i.e. using your own subscription ID inside a Resource ID string). See details in the [Parameter File Tokens Design](./ParameterFileTokens.md). The repository contains a [Settings.json](https://github.com/Azure/ResourceModules/blob/main/settings.json) that enables you to define local tokens and store them in source control. The token format is a `name` and `value` pair as shown in the following example: @@ -203,7 +203,7 @@ Once the Key Vault is deployed, you'll notice that the Key Vault name in Azure w > The token prefix `<<` and suffix `>>` in the above example are also configurable in the [Settings.json](https://github.com/Azure/ResourceModules/blob/main/settings.json) file. They are however the default used in the CARML main repository. --- -Note: There are default tokens that can be enabled on any resource that leverages the [GitHub specific prerequisites](GettingStarted#github-specific-prerequisites) secrets. +Note: There are default tokens that can be enabled on any resource that leverages the [GitHub specific prerequisites](GettingStarted.md#github-specific-prerequisites) secrets. - `<>`: Will point to the Azure subscription. - `<>`: Will point to the Azure an Azure Management Group. diff --git a/docs/wiki/Home.md b/docs/wiki/Home.md index c900a946b7..4d2e2ae0fa 100644 --- a/docs/wiki/Home.md +++ b/docs/wiki/Home.md @@ -4,27 +4,27 @@ The objective of this repository is to provide a template library that can be re This wiki describes the content of this repository, the modules, pipelines, possible options on how to use them and how to contribute to this project. -If you're unfamiliar with Infrastructure as Code, or wonder how you can use the contents of this repository in your deployments please check out the [context](./Context) section of this wiki. +If you're unfamiliar with Infrastructure as Code, or wonder how you can use the contents of this repository in your deployments please check out the [context](./Context.md) section of this wiki. ### _Navigation_ -- [Context](./Context) - - [Infrastructure as Code](./Context#infrastructure-as-code-iac) - - [Where does this platform fit in?](./Context#where-does-this-platform-fit-in) -- [Getting Started](./GettingStarted) - - [General prerequisites](./GettingStarted#General-prerequisites) - - [Where to start](./GettingStarted#Where-to-start) -- [Modules](./Modules) - - [Design](./ModulesDesign) - - [Usage](./ModulesUsage) -- [Testing](./Testing) - - [Design](./TestingDesign) - - [Usage](./TestingUsage) -- [Pipelines](./Pipelines) - - [Design](./PipelinesDesign) - - [Usage](./PipelinesUsage) -- [Contribution Guide](./ContributionGuide) -- [Known Issues](./KnownIssues) +- [Context](./Context.md) + - [Infrastructure as Code](./Context.md#infrastructure-as-code-iac) + - [Where does this platform fit in?](./Context.md#where-does-this-platform-fit-in.md) +- [Getting Started](./GettingStarted.md) + - [General prerequisites](./GettingStarted.md#General-prerequisites.md) + - [Where to start](./GettingStarted.md#Where-to-start.md) +- [Modules](./Modules.md) + - [Design](./ModulesDesign.md) + - [Usage](./ModulesUsage.md) +- [Testing](./Testing.md) + - [Design](./TestingDesign.md) + - [Usage](./TestingUsage.md) +- [Pipelines](./Pipelines.md) + - [Design](./PipelinesDesign.md) + - [Usage](./PipelinesUsage.md) +- [Contribution Guide](./ContributionGuide.md) +- [Known Issues](./KnownIssues.md) # Scope @@ -33,7 +33,7 @@ Following you can find an abstract overview of everything in- and out-of-scope o ## In Scope - **Modules:** Rich library of resource modules - the foundation for workload or entire environments deployments - **Platform:** Pipelines to validate modules & publish to those that pass to a location of your choice. Available with GitHub Workflows. -- **Documentation:** A rich documentation of best practices on [module](./Modules) design, the [platforms](./Context) and its [context](./Context), [testing](./Testing) and [pipelines](./Pipelines) +- **Documentation:** A rich documentation of best practices on [module](./Modules.md) design, the [platforms](./Context.md) and its [context](./Context.md), [testing](./Testing.md) and [pipelines](./Pipelines.md) ## Out of Scope - **Orchestration:** Orchestrated solutions such as workloads or entire environments intended for production environments diff --git a/docs/wiki/Modules.md b/docs/wiki/Modules.md index 8f47239754..2b0bbad7d8 100644 --- a/docs/wiki/Modules.md +++ b/docs/wiki/Modules.md @@ -6,12 +6,12 @@ This section and its sub-sections give you an overview of the principals the mod ### _Navigation_ -- [Module Design](./ModulesDesign) - - [General guidelines](./ModulesDesign#general-guidelines) - - [File & folder structure](./ModulesDesign#file--folder-structure) - - [Bicep template guidelines](./ModulesDesign#bicep-template-guidelines) -- [Module Usage](./ModulesUsage) - - [Deploy local template](./ModulesUsage#deploy-local-template) - - [Deploy remote template](./ModulesUsage#deploy-remote-template) +- [Module Design](./ModulesDesign.md) + - [General guidelines](./ModulesDesign.md#general-guidelines) + - [File & folder structure](./ModulesDesign.md#file--folder-structure) + - [Bicep template guidelines](./ModulesDesign.md#bicep-template-guidelines) +- [Module Usage](./ModulesUsage.md) + - [Deploy local template](./ModulesUsage.md#deploy-local-template) + - [Deploy remote template](./ModulesUsage.md#deploy-remote-template) --- diff --git a/docs/wiki/ModulesDesign.md b/docs/wiki/ModulesDesign.md index 68e169b2cd..4c57ba5478 100644 --- a/docs/wiki/ModulesDesign.md +++ b/docs/wiki/ModulesDesign.md @@ -144,7 +144,7 @@ Microsoft.Sql In this folder we recommend to place the child-resource-template alongside a ReadMe (that can be generated via the `.github\workflows\scripts\Set-ModuleReadMe.ps1` script) and optionally further nest additional folders for it's child-resources. -The parent template should reference all it's direct child-templates to allow for an end to end deployment experience while allowing any user to also reference 'just' the child-resource itself. In the case of the SQL-server example the server template would reference the database module and encapsulate it it in a loop to allow for the deployment of n-amount of databases. For example +The parent template should reference all it's direct child-templates to allow for an end-to-end deployment experience while allowing any user to also reference 'just' the child-resource itself. In the case of the SQL-server example the server template would reference the database module and encapsulate it it in a loop to allow for the deployment of n-amount of databases. For example ```Bicep @description('Optional. The databases to create in the server') @@ -476,7 +476,7 @@ Within a bicep file, follow the following conventions: ``` - Bicep `modules`: - camel_Snake_Case, i.e `resourceGroup_rbac` ? - - File name for nested module is structured as follows: `nested_.bicep` i.e: + - Filename for nested module is structured as follows: `nested_.bicep` i.e: - `nested_rbac.bicep` @@ -493,7 +493,7 @@ Within a bicep file, follow the following conventions: # ReadMe -Each module must come with a ReadMe markdown file that outlines what the module contains and 'how' it can be used. +Each module must come with a ReadMe Markdown file that outlines what the module contains and 'how' it can be used. It primary components are - A title with a reference to the primary resource (for example KeyVault `[Microsoft.KeyVault/vaults]`) - A description diff --git a/docs/wiki/ModulesUsage.md b/docs/wiki/ModulesUsage.md index ce425ceda3..726dad6f29 100644 --- a/docs/wiki/ModulesUsage.md +++ b/docs/wiki/ModulesUsage.md @@ -70,7 +70,7 @@ New-AzResourceGroup -Name 'ExampleGroup' -Location "Central US" $inputObject = @{ DeploymentName = 'ExampleDeployment' ResourceGroupName = 'ExampleGroup' - TemplateUri = 'https://raw.githubusercontent.com/arm/ResourceModules/main/arm/Microsoft.KeyVault/vaults/deploy.json' + TemplateUri = 'https://raw.githubusercontent.com/Azure/ResourceModules/main/arm/Microsoft.KeyVault/vaults/deploy.bicep' } New-AzResourceGroupDeployment @inputObject ``` @@ -83,7 +83,7 @@ az group create --name 'ExampleGroup' --location "Central US" $inputObject = @( '--name', 'ExampleDeployment', '--resource-group', 'ExampleGroup', - '--template-uri', 'https://raw.githubusercontent.com/arm/ResourceModules/main/arm/Microsoft.KeyVault/vaults/deploy.json', + '--template-uri', 'https://raw.githubusercontent.com/Azure/ResourceModules/main/arm/Microsoft.KeyVault/vaults/deploy.bicep', '--parameters', 'storageAccountType=Standard_GRS', ) az deployment group create @inputObject diff --git a/docs/wiki/ParameterFileTokens.md b/docs/wiki/ParameterFileTokens.md index 12523b7acc..2004a2576b 100644 --- a/docs/wiki/ParameterFileTokens.md +++ b/docs/wiki/ParameterFileTokens.md @@ -30,7 +30,7 @@ There are (2) Token types that can be applied on a Parameter File: #### 1. Default Tokens (Environment Variables) [Default] -These are tokens constructed from Environment Variables, which are defined in the Workflow (Pipeline). Review [Getting Started - GitHub specific prerequisites](./GettingStarted) for more information on these Environment Variables. +These are tokens constructed from Environment Variables, which are defined in the Workflow (Pipeline). Review [Getting Started - GitHub specific prerequisites](./GettingStarted.md) for more information on these Environment Variables. #### 2. Local Custom Tokens (Source Control) [Optional] diff --git a/docs/wiki/Pipelines.md b/docs/wiki/Pipelines.md index 5a4a421ec7..540dc80467 100644 --- a/docs/wiki/Pipelines.md +++ b/docs/wiki/Pipelines.md @@ -8,7 +8,7 @@ This section and its sub-sections give you an overview of the principals the pip ### _Navigation_ -- [Pipelines Design](./PipelinesDesign) -- [Pipelines Usage](./PipelinesUsage) +- [Pipelines Design](./PipelinesDesign.md) +- [Pipelines Usage](./PipelinesUsage.md) --- diff --git a/docs/wiki/PipelinesDesign.md b/docs/wiki/PipelinesDesign.md index 87e787d57d..4d00b20b09 100644 --- a/docs/wiki/PipelinesDesign.md +++ b/docs/wiki/PipelinesDesign.md @@ -76,7 +76,7 @@ The validation phase performs all test outside of a test deployment. This includ #### Static module validation -This static validation executes the tests documented in the [testing](./Testing) section. Without diving into to much detail, we test aspects like a proper ReadMe documentation, a proper module folder structure, a minimum number of refresh of the leveraged of API versions and the like. +This static validation executes the tests documented in the [testing](./Testing.md) section. Without diving into to much detail, we test aspects like a proper ReadMe documentation, a proper module folder structure, a minimum number of refresh of the leveraged of API versions and the like. #### Simulated deployment validation @@ -159,7 +159,7 @@ Dynamic parameters that do not need to be hardcoded in the parameter file, and t For example, some modules require referencing Azure resources with the Resource ID. This ID typically contains the `subscriptionId` in the format of `/subscriptions/<>/...`. This task substitutes the `<>` with the correct value, based on the different token types. -Please review the Parameter File Tokens [Design](./ParameterFileTokens) for more details on the different token types and how you can use them to remove hardcoded values from your parameter files. +Please review the Parameter File Tokens [Design](./ParameterFileTokens.md) for more details on the different token types and how you can use them to remove hardcoded values from your parameter files. --- @@ -173,7 +173,7 @@ Outside of the previously described platform pipelines we implemented several ad ## Dependencies pipeline -As the modules we test often times have dependencies to other services, we created a pipeline to deploys several standard services like VirtualNetworks and KeyVaults (alongside dummy secrets) for the modules to use. This _dependency_ pipeline should be prepared and executed before you start running any pipelines on your own. In case you need to rename any services there (for example because a certain globally unique resource name was already taken) make sure to update any references to this name in the module parameter files. You can find further details about this pipeline [here](.\TestingDesign#Module-Dependencies). +As the modules we test often times have dependencies to other services, we created a pipeline to deploys several standard services like VirtualNetworks and KeyVaults (alongside dummy secrets) for the modules to use. This _dependency_ pipeline should be prepared and executed before you start running any pipelines on your own. In case you need to rename any services there (for example because a certain globally unique resource name was already taken) make sure to update any references to this name in the module parameter files. You can find further details about this pipeline [here](./TestingDesign.md#Module-Dependencies). ### Dependencies pipeline inputs diff --git a/docs/wiki/PipelinesUsage.md b/docs/wiki/PipelinesUsage.md index 45e652c650..8f9a6f1594 100644 --- a/docs/wiki/PipelinesUsage.md +++ b/docs/wiki/PipelinesUsage.md @@ -19,14 +19,14 @@ This section gives you an overview of how to interact with the platform pipeline When working with this platform's pipelines it is important to understand first which pipelines serve which purpose, when they are triggered and how you can use them to test your modules. -As described in the [Pipelines Design](./PipelinesDesign) section we offer the following pipelines: +As described in the [Pipelines Design](./PipelinesDesign.md) section we offer the following pipelines: | Pipeline | Target | Trigger | Notes | | - | - | - | - | -| [Module Pipelines](./PipelinesDesign#module-pipelines) | Module | Changes to [module\|workflow] files in branch [main\|master] or manual | Used to test & publish modules. This is the most common pipeline you will interact with when working on modules. | -| [Dependencies pipeline](./PipelinesDesign#dependencies-pipeline) | All required dependency resources | Manual | Deploys resources we reference in the module tests. Should be run once before testing modules. | -| [ReadMe pipeline](./PipelinesDesign#readme-pipeline) | `README.md` in `` & `/arm` | Changes to [template files] in branch [main\|master] | Keeps the target ReadMe files aligned with the modules in the repository. | -| [Wiki pipeline](./PipelinesDesign#wiki-pipeline) | Wiki | Changes in [docs/wiki] in branch [main\|master] | Keeps the Wiki-repository in sync with the wiki folder in the modules repository | +| [Module Pipelines](./PipelinesDesign.md#module-pipelines) | Module | Changes to [module\|workflow] files in branch [main\|master] or manual | Used to test & publish modules. This is the most common pipeline you will interact with when working on modules. | +| [Dependencies pipeline](./PipelinesDesign.md#dependencies-pipeline) | All required dependency resources | Manual | Deploys resources we reference in the module tests. Should be run once before testing modules. | +| [ReadMe pipeline](./PipelinesDesign.md#readme-pipeline) | `README.md` in `` & `/arm` | Changes to [template files] in branch [main\|master] | Keeps the target ReadMe files aligned with the modules in the repository. | +| [Wiki pipeline](./PipelinesDesign.md#wiki-pipeline) | Wiki | Changes in [docs/wiki] in branch [main\|master] | Keeps the Wiki-repository in sync with the wiki folder in the modules repository | --- @@ -49,7 +49,7 @@ To validate any updates you did to a module template you can perform the followi Once the pipeline concluded, it will either be in a green (success) or red (failed) state, depending on how the module performed. -If you open the pipeline's run, you should be able to investigate the logs and investigate the execution. In case any of the [validation](./PipelinesDesign#Validate) steps failed, the pipeline should give you detailed information of any error. In some cases in which Pester tests failed, you may only see the failed test and need to `expand` the error message. How this looks like depends on the [DevOps platform](#devops-tool-specific-considerations) you use. +If you open the pipeline's run, you should be able to investigate the logs and investigate the execution. In case any of the [validation](./PipelinesDesign.md#Validate) steps failed, the pipeline should give you detailed information of any error. In some cases in which Pester tests failed, you may only see the failed test and need to `expand` the error message. How this looks like depends on the [DevOps platform](#devops-tool-specific-considerations) you use. ## Operate the dependency pipeline @@ -57,13 +57,13 @@ As described previously, the dependency pipeline must be triggered manually and Triggering the pipeline is as easy as navigating to it in your corresponding DevOps tool and running the pipeline. No additional steps or input parameters are required. -> **Note:** While operating the dependency pipeline is simple, make sure to set it up in the way it is described [here](./GettingStarted#Dependencies). Especially the globally unique names must be accounted for, before executing the pipeline. +> **Note:** While operating the dependency pipeline is simple, make sure to set it up in the way it is described [here](./GettingStarted.md#Dependencies). Especially the globally unique names must be accounted for, before executing the pipeline. -Depending on what you want to test in your module pipeline, you may want to add additional dependencies to your dependency pipeline. If so, make sure to add an additional parameter file for each service you require under `utilities/pipelines/dependencies`. Once done, you just need to add the deployment to the pipeline itself in the correct location in the pipeline. The different deployment waves are documented [here](./TestingDesign#module-dependencies). The implementation depends on the [DevOps tool](#devops-tool-specific-considerations) you're using. +Depending on what you want to test in your module pipeline, you may want to add additional dependencies to your dependency pipeline. If so, make sure to add an additional parameter file for each service you require under `utilities/pipelines/dependencies`. Once done, you just need to add the deployment to the pipeline itself in the correct location in the pipeline. The different deployment waves are documented [here](./TestingDesign.md#module-dependencies). The implementation depends on the [DevOps tool](#devops-tool-specific-considerations) you're using. ## Add a new module pipeline -To add a new module pipeline we recommend to create a copy of a currently existing module pipeline and adjust all module-specific properties documented [here](./PipelinesDesign#component-workflows). The registration of the pipeline will differ depending on the DevOps tool you're using. For further information, please review the [DevOps-Tool-specific guidance](#devops-tool-specific-guidance) below. +To add a new module pipeline we recommend to create a copy of a currently existing module pipeline and adjust all module-specific properties documented [here](./PipelinesDesign.md#component-workflows). The registration of the pipeline will differ depending on the DevOps tool you're using. For further information, please review the [DevOps-Tool-specific guidance](#devops-tool-specific-guidance) below. --- @@ -86,7 +86,7 @@ then select the pipeline of your choice from the list on the left, followed by ' Run workflow Depending on the pipeline you selected you may have additional input parameters you can provide aside from the branch: -- [Module pipeline](./TestingDesign#module-pipeline-inputs) inputs +- [Module pipeline](./TestingDesign.md#module-pipeline-inputs) inputs ### Register a pipeline diff --git a/docs/wiki/Testing.md b/docs/wiki/Testing.md index 7383346162..4d9a0dbc66 100644 --- a/docs/wiki/Testing.md +++ b/docs/wiki/Testing.md @@ -6,11 +6,11 @@ This section and its sub-sections give you an overview of the principles the tes ### _Navigation_ -- [Testing Design](./TestingDesign) - - [Approach](./TestingDesign#approach) - - [API version validation](./TestingDesign#api-version-validation) - - [Template validation](./TestingDesign#template-validation) - - [Deployment validation](./TestingDesign#deployment-validation) -- [Testing Usage](./TestingUsage) +- [Testing Design](./TestingDesign.md) + - [Approach](./TestingDesign.md#approach) + - [API version validation](./TestingDesign.md#api-version-validation) + - [Template validation](./TestingDesign.md#template-validation) + - [Deployment validation](./TestingDesign.md#deployment-validation) +- [Testing Usage](./TestingUsage.md) --- diff --git a/docs/wiki/TestingDesign.md b/docs/wiki/TestingDesign.md index dea558d6e0..5b09fbab31 100644 --- a/docs/wiki/TestingDesign.md +++ b/docs/wiki/TestingDesign.md @@ -63,7 +63,7 @@ The following activities are run executing the `arm/.global/global.module.tests. - [Pester Wiki](https://github.com/pester/Pester/wiki) - [Pester on GitHub](https://github.com/pester/Pester) -- [Pester Setup and Commands](https://pester.dev/docs/commands/Setup) +- [Pester Installation and Update](https://pester.dev/docs/introduction/installation) --- @@ -81,9 +81,9 @@ The template validation tests execute a dry-run with each parameter file provide # Deployment validation -If all other tests passed, the deployment tests are the ultimate module validation. Using the available & configured parameter files for a module, each is deployed to Azure (in parallel) and verifies if the deployment works end to end. +If all other tests passed, the deployment tests are the ultimate module validation. Using the available & configured parameter files for a module, each is deployed to Azure (in parallel) and verifies if the deployment works end-to-end. -Most of the resources are deleted by default after their deployment, to keep costs down and to be able to retest resource modules from scratch in the next run. However, the removal step can be skipped in case further investigation on the deployed resource is needed. For further details, please refer to the (./PipelinesUsage) section. +Most of the resources are deleted by default after their deployment, to keep costs down and to be able to retest resource modules from scratch in the next run. However, the removal step can be skipped in case further investigation on the deployed resource is needed. For further details, please refer to the (./PipelinesUsage.md) section. This happens using the `.github/actions/templates/validateModuleDeploy/scripts/Test-TemplateWithParameterFile.ps1` script. diff --git a/docs/wiki/TestingUsage.md b/docs/wiki/TestingUsage.md index 8f3ac509ef..7cb753b281 100644 --- a/docs/wiki/TestingUsage.md +++ b/docs/wiki/TestingUsage.md @@ -73,7 +73,7 @@ $TestModuleLocallyInput = @{ ## Handling Parameters that require or contain a value that should be tokenized -The following scenarios are common to when to use a token value in the parameter file. Refer to [Parameter File Tokens Design](./ParameterFileTokens) for more details. +The following scenarios are common to when to use a token value in the parameter file. Refer to [Parameter File Tokens Design](./ParameterFileTokens.md) for more details. - Scenarios where resources have dependencies on other resources, which may require to be linked using `resourceId` references. diff --git a/docs/wiki/_Sidebar.md b/docs/wiki/_Sidebar.md index 93fb2cee55..3e90ad12a4 100644 --- a/docs/wiki/_Sidebar.md +++ b/docs/wiki/_Sidebar.md @@ -1,17 +1,17 @@ # Wiki content -- [Home](./Home) -- [Context](./Context) -- [Getting Started](./GettingStarted) -- [Modules](./Modules) - - [Design](./ModulesDesign) - - [Usage](./ModulesUsage) -- [Testing](./Testing) - - [Design](./TestingDesign) - - [Usage](./TestingUsage) -- [Pipelines](./Pipelines) - - [Design](./PipelinesDesign) - - [Parameter File Tokens](./ParameterFileTokens) - - [Usage](./PipelinesUsage) -- [Contribution Guide](./ContributionGuide) -- [Known Issues](./KnownIssues) +- [Home](./Home.md) +- [Context](./Context.md) +- [Getting Started](./GettingStarted.md) +- [Modules](./Modules.md) + - [Design](./ModulesDesign.md) + - [Usage](./ModulesUsage.md) +- [Testing](./Testing.md) + - [Design](./TestingDesign.md) + - [Usage](./TestingUsage.md) +- [Pipelines](./Pipelines.md) + - [Design](./PipelinesDesign.md) + - [Parameter File Tokens](./ParameterFileTokens.md) + - [Usage](./PipelinesUsage.md) +- [Contribution Guide](./ContributionGuide.md) +- [Known Issues](./KnownIssues.md)