Merge branch 'main' of https://github.com/microsoft/AL-Go into aholstrup/inlinepowershell

Author: aholstrup1

Scenarios/settings.md

@@ -77,7 +77,7 @@ The repository settings are only read from the repository settings file (.github
 | <a id="aldoc"></a>alDoc | Structure with properties for the aldoc reference document generation. The structure can contain the following properties:<br />**continuousDeployment** = Determines if reference documentation will be deployed continuously as part of CI/CD. You can run the **Deploy Reference Documentation** workflow to deploy manually or on a schedule. (Default false)<br />**deployToGitHubPages** = Determines whether or not the reference documentation site should be deployed to GitHub Pages for the repository. In order to deploy to GitHub Pages, GitHub Pages must be enabled and set to GitHub Actuibs. (Default true)<br />**maxReleases** = Maximum number of releases to include in the reference documentation. (Default 3)<br />**groupByProject** = Determines whether projects in multi-project repositories are used as folders in reference documentation<br />**includeProjects** = An array of projects to include in the reference documentation. (Default all)<br />**excludeProjects** = An array of projects to exclude in the reference documentation. (Default none)<br />**header** = Header for the documentation site. (Default: Documentation for...)<br />**footer** = Footer for the documentation site. (Default: Made with...)<br />**defaultIndexMD** = Markdown for the landing page of the documentation site. (Default: Reference documentation...)<br />**defaultReleaseMD** = Markdown for the landing page of the release sites. (Default: Release reference documentation...)<br />*Note that in header, footer, defaultIndexMD and defaultReleaseMD you can use the following placeholders: {REPOSITORY}, {VERSION}, {INDEXTEMPLATERELATIVEPATH}, {RELEASENOTES}* |
 | <a id="useProjectDependencies"></a>useProjectDependencies | Determines whether your projects are built using a multi-stage built workflow or single stage. After setting useProjectDependencies to true, you need to run Update AL-Go System Files and your workflows including a build job will change to have multiple build jobs, depending on each other. The number of build jobs will be determined by the dependency depth in your projects.<br />You can change dependencies between your projects, but if the dependency **depth** changes, AL-Go will warn you that updates for your AL-Go System Files are available and you will need to run the workflow. |
 | <a id="CICDPushBranches"></a>CICDPushBranches | CICDPushBranches can be specified as an array of branches, which triggers a CI/CD workflow on commit. You need to run the Update AL-Go System Files workflow for the change to take effect.<br />Default is [ "main", "release/\*", "feature/\*" ]<br /><br />**Supported release branch naming formats:**<br />When using release branches, AL-Go supports various naming conventions for matching previous releases during upgrade testing. The following formats are recognized:<br />• `releases/26` - matches releases with major version 26<br />• `releases/26.x` - matches releases with major version 26<br />• `releases/26x` - matches releases with major version 26<br />• `releases/v26` - matches releases with major version 26<br />• `releases/v26.x` - matches releases with major version 26<br />• `releases/v26x` - matches releases with major version 26<br />• `releases/26.3` - matches releases with major.minor version 26.3<br />The same patterns work with the singular `release/` prefix. |
-| <a id="CICDPullrequestBranches"></a>CICDPullRequestBranches | CICDPullRequestBranches can be specified as an array of branches, which triggers a CI/CD workflow on a PR. You need to run the Update AL-Go System Files workflow for the change to take effect.<br />Default is [ "main" ] |
+| <a id="CICDPullRequestBranches"></a>CICDPullRequestBranches | CICDPullRequestBranches can be specified as an array of branches (branch patterns). A Pull Request Build will be triggered when a PR targets a branch that matches one of the patterns in this list. You need to run the Update AL-Go System Files workflow for the change to take effect.<br />Default is [ "main" ] |
 | <a id="pullRequestTrigger"></a>pullRequestTrigger | Setting for specifying the trigger AL-Go should use to trigger Pull Request Builds. Note that when using the default `pull_request` trigger, secrets are not available to the workflow for pull requests from forks. If you need secret access for fork PRs, you can set this to `pull_request_target`, but make sure you understand the [security implications](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target) first. You need to run the Update AL-Go System Files workflow for the change to take effect.<BR />Default is [pull_request](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request) |
 | <a id="buildModes"></a>buildModes | A list of build modes to use when building the AL-Go projects. Every AL-Go project will be built using each build mode. The following build modes have special meaning in AL-Go:<br /> **Default**: Apps are compiled as they are in the source code.<br />**Clean**: Should be used for Clean Mode. Use [Conditional Settings](https://aka.ms/algosettings#conditional-settings) with buildMode set the 'Clean' to specify preprocessorSymbols for clean mode.<br />**Translated**: `TranslationFile` compiler feature is enabled when compiling the apps.<br /><br />It is also possible to specify custom build modes by adding a build mode that is different than 'Default', 'Clean' or 'Translated' and use [conditional settings](https://aka.ms/algosettings#conditional-settings) to specify preprocessor symbols and other build settings for the build mode. |
 | <a id="useGitSubmodules"></a>useGitSubmodules | If your repository is using Git Submodules, you can set the `useGitSubmodules` setting to `"true"` or `"recursive"` in order to use these submodules during build workflows. If `useGitSubmodules` is not set, git submodules are not initialized. If the submodules reside in private repositories, you need to define a `gitSubmodulesToken` secret. Read [this](https://aka.ms/algosecrets#gitSubmodulesToken) for more information. |