|
| 1 | +## v8.1 |
| 2 | + |
| 3 | +### Custom AL-Go files |
| 4 | + |
| 5 | +AL-Go for GitHub now supports updating files from your custom templates via the new `customALGoFiles` setting. Read more at [customALGoFiles](https://aka.ms/algosettings#customALGoFiles). |
| 6 | + |
| 7 | +### Set default values for workflow inputs |
| 8 | + |
| 9 | +A new setting `workflowDefaultInputs` allows you to configure default values for workflow_dispatch inputs. This makes it easier to run workflows manually with consistent settings across your team. |
| 10 | + |
| 11 | +When you add this setting to your AL-Go settings file and run the "Update AL-Go System Files" workflow, the default values will be automatically applied to the workflow YAML files in your repository. |
| 12 | +The default values must match the input types (boolean, number, string, or choice) defined in the workflow YAML files. |
| 13 | + |
| 14 | +Example configuration: |
| 15 | + |
| 16 | +```json |
| 17 | +{ |
| 18 | + "workflowDefaultInputs": [ |
| 19 | + { "name": "directCommit", "value": true }, |
| 20 | + { "name": "useGhTokenWorkflow", "value": true } |
| 21 | + ] |
| 22 | +} |
| 23 | +``` |
| 24 | + |
| 25 | +This setting can be used on its own in repository settings to apply defaults to all workflows with matching input names. Alternatively, you can use it within [conditional settings](https://aka.ms/algosettings#conditional-settings) to apply defaults only to specific workflows, branches, or other conditions. |
| 26 | + |
| 27 | +Example using conditional settings to target specific workflows: |
| 28 | + |
| 29 | +```json |
| 30 | +{ |
| 31 | + "conditionalSettings": [ |
| 32 | + { |
| 33 | + "workflows": ["Create Release"], |
| 34 | + "settings": { |
| 35 | + "workflowDefaultInputs": [ |
| 36 | + { "name": "directCommit", "value": true }, |
| 37 | + { "name": "releaseType", "value": "Prerelease" } |
| 38 | + ] |
| 39 | + } |
| 40 | + } |
| 41 | + ] |
| 42 | +} |
| 43 | +``` |
| 44 | + |
| 45 | +**Important:** When multiple conditional settings blocks match and both define `workflowDefaultInputs`, the arrays are merged following AL-Go's standard behavior for complex setting types (all entries are kept). If the same input name appears in multiple entries, the last matching entry takes precedence. |
| 46 | + |
| 47 | +Read more at [workflowDefaultInputs](https://aka.ms/algosettings#workflowDefaultInputs). |
| 48 | + |
| 49 | +### Issues |
| 50 | + |
| 51 | +- Issue 2039 Error when deploy to environment: NewTemporaryFolder is not recognized |
| 52 | +- Issue 1961 KeyVault access in PR pipeline |
| 53 | +- Discussion 1911 Add support for reportSuppressedDiagnostics |
| 54 | +- Discussion 1968 Parameter for settings passed to CreateDevEnv |
| 55 | +- Issue 1945 Deploy Reference Documentation fails for CI/CD |
| 56 | +- Use Runner_Temp instead of GetTempFolder whenever possible |
| 57 | +- Issue 2016 Running Update AL-Go system files with branches wildcard `*` tries to update _origin_ |
| 58 | +- Issue 1960 Deploy Reference Documentation fails |
| 59 | +- Discussion 1952 Set default values on workflow_dispatch input |
| 60 | + |
| 61 | +### Deprecations |
| 62 | + |
| 63 | +- `unusedALGoSystemFiles` will be removed after October 1st 2026. Please use [`customALGoFiles.filesToExclude`](https://aka.ms/algosettings#customALGoFiles) instead. |
| 64 | + |
| 65 | +## v8.0 |
| 66 | + |
| 67 | +### Mechanism to overwrite complex settings type |
| 68 | + |
| 69 | +By default, AL-Go merges settings from various places (see [settings levels](https://aka.ms/algosettings#where-are-the-settings-located)). Basic setting types such as `string` and `integer` are overwritten, but settings with complex types such as `array` and `object` are merged. |
| 70 | + |
| 71 | +However, sometimes it is useful to avoid merging complex types. This can be achieved by specifying `overwriteSettings` property on a settings object. The purpose of the property is to list settings, for which the value will be overwritten, instead of merged. Read more at [overwriteSettings property](https://aka.ms/algosettings#overwriteSettings) |
| 72 | + |
| 73 | +### AL Code Analysis tracked in GitHub |
| 74 | + |
| 75 | +AL-Go already supports AL code analysis, but up until now this was not tracked in GitHub. It is now possible to track code analysis issues automatically in the GitHub security tab, as well as having any new issues posted as a comment in Pull Requests. |
| 76 | + |
| 77 | +Enable this feature by using the new setting [trackALAlertsInGithub](https://aka.ms/algosettings#trackALAlertsInGithub). This setting must be enabled at the repo level, but can optionally be disabled per project. |
| 78 | + |
| 79 | +Please note that some automated features are premium and require the use of [GitHub Code Security](https://docs.github.com/en/get-started/learning-about-github/about-github-advanced-security) |
| 80 | + |
| 81 | +### Issues |
| 82 | + |
| 83 | +- Discussion 1885 Conditional settings for CI/CD are not applied |
| 84 | +- Discussion 1899 Remove optional properties from "required" list in settings.schema.json |
| 85 | +- Issue 1905 AL-Go system files update fails (Get Workflow Multi-Run Branches action fails when there are tags with same value but different casing) |
| 86 | +- Issue 1926 Deployment fails when using build modes |
| 87 | +- Issue 1898 GetDependencies in localDevEnv does not fallback to github token |
| 88 | +- Issue 1947 Project settings are ignored when loading bccontainerhelper |
| 89 | +- Issue 1937 trackALAlertsInGitHub is failing in preview |
| 90 | +- DeployTo settings from environment-specific AL-Go settings are not applied when deploying |
| 91 | +- `ReadSettings` action outputs too much information that is mainly used for debugging |
| 92 | + |
| 93 | +## v7.3 |
| 94 | + |
| 95 | +### Configurable merge method for pull request auto-merge |
| 96 | + |
| 97 | +A new setting `pullRequestMergeMethod` has been added to the `commitOptions` structure, allowing you to configure which merge method to use when `pullRequestAutoMerge` is enabled. Valid values are "merge" or "squash". The default value is "squash" to maintain backward compatibility. |
| 98 | + |
| 99 | +Example |
| 100 | + |
| 101 | +```json |
| 102 | +{ |
| 103 | + "commitOptions": { |
| 104 | + "pullRequestAutoMerge": true, |
| 105 | + "pullRequestMergeMethod": "merge" |
| 106 | + } |
| 107 | +} |
| 108 | +``` |
| 109 | + |
| 110 | +### AL-Go Telemetry |
| 111 | + |
| 112 | +AL-Go now offers a dataexplorer dashboard to get started with AL-Go telemetry. Additionally, we've updated the documentation to include a couple of kusto queries if you would rather build your own reports. |
| 113 | + |
| 114 | +### Support for AL-Go settings as GitHub environment variable: ALGoEnvironmentSettings |
| 115 | + |
| 116 | +AL-Go settings can now be defined in GitHub environment variables. To use this feature, create a new variable under your GitHub environment called `ALGoEnvironmentSettings`. Please note that this variable should not include your environment name. |
| 117 | + |
| 118 | +Settings loaded this way, will only be available during the Deploy step of the CI/CD or Publish to Environment actions, but not the Build step, making it most suitable for the [DeployTo setting](https://aka.ms/algosettings#deployto). Settings defined in this variable will take priority over any setting defined in AL-Go repo, org or settings files. |
| 119 | + |
| 120 | +The contents of the variable should be a JSON block, similar to any other settings file or variable. When defining the `DeployTo\<EnvName>` setting in this variable, it should still include the environment name. Eg: |
| 121 | + |
| 122 | +``` |
| 123 | +{ |
| 124 | + DeployToProduction { |
| 125 | + "Branches": [ |
| 126 | + "*" |
| 127 | + ], |
| 128 | + "includeTestAppsInSandboxEnvironment": false, |
| 129 | + "excludeAppIds": [ 1234 ] |
| 130 | + } |
| 131 | +} |
| 132 | +``` |
| 133 | + |
| 134 | +Please note, that due to certain security limitations, the properties `runs-on`, `shell` and `ContinousDeployment` of the `DeployTo` setting will <ins>**NOT**</ins> be respected if defined in a GitHub environment variable. To use these properties, please keep them defined elsewhere, such as your AL-Go settings file or Org/Repo settings variables. |
| 135 | + |
| 136 | +### Issues |
| 137 | + |
| 138 | +- Issue 1770 Wrong type of _projects_ setting in settings schema |
| 139 | +- Issue 1787 Publish to Environment from PR fails in private repos |
| 140 | +- Issue 1722 Check if apps are already installed on a higher version before deploying |
| 141 | +- Issue 1774 Increment Version Number with +0.1 can increment some version numbers twice |
| 142 | +- Issue 1837 Deployment from PR builds fail if PR branch name includes forward slashes (e.g., `feature/branch-name`). |
| 143 | +- Issue 1852 Page Scripting Tests are not added to build summary |
| 144 | +- Issue 1829 Added custom jobs cannot be removed |
| 145 | +- Idea 1856 Include workflow name as input for action ReadSetting |
| 146 | + |
| 147 | +### Additional debug logging functionality |
| 148 | + |
| 149 | +We have improved how logging is handled in AL-Go, and now make better use of GitHub built-in extended debug logging functionality. Extended debug logging can be enabled when re-running actions by clicking the 'Enable debug logging' checkbox in the pop-up window. This can be done both for jobs that failed and jobs that succeeded, but did not produce the correct result. |
| 150 | + |
| 151 | +### Add custom jobs to AL-Go workflows |
| 152 | + |
| 153 | +It is now possible to add custom jobs to AL-Go workflows. The Custom Job needs to be named `CustomJob<something>` and should be placed after all other jobs in the .yaml file. The order of which jobs are executed is determined by the Needs statements. Your custom job will be executed after all jobs specified in the Needs clause in your job and if you need the job to be executed before other jobs, you should add the job name in the Needs clause of that job. See [https://aka.ms/algosettings#customjobs](https://aka.ms/algosettings#customjobs) for details. |
| 154 | + |
| 155 | +Note that custom jobs might break by future changes to AL-Go for GitHub workflows. If you have customizations to AL-Go for GitHub workflows, you should always doublecheck the pull request generated by Update AL-Go System Files. |
| 156 | + |
| 157 | +### Support for Custom AL-Go template repositories |
| 158 | + |
| 159 | +Create an AL-Go for GitHub repository based on [https://aka.ms/algopte](https://aka.ms/algopte) or [https://aka.ms/algoappsource](https://aka.ms/algoappsource), add custom workflows, custom jobs and/or settings to this repository and then use that repository as the template repository for other repositories. Using custom template repositories allows you to create and use highly customized template repositories and control the uptake of this in all repositories. See [https://aka.ms/algosettings#customtemplate](https://aka.ms/algosettings#customtemplate) for details. |
| 160 | + |
| 161 | +> [!NOTE] |
| 162 | +> Customized repositories might break by future changes to AL-Go for GitHub. If you are customizing AL-Go for GitHub, you should always double-check the pull request when updating AL-Go system files in your custom template repositories. |
| 163 | +
|
1 | 164 | ## v7.2 |
2 | 165 |
|
3 | 166 | ### Removed functionality |
@@ -818,7 +981,7 @@ Setting the repo setting "runs-on" to "Ubuntu-latest", followed by running Updat |
818 | 981 | ### Issues |
819 | 982 |
|
820 | 983 | - Issue #143 Commit Message for **Increment Version Number** workflow |
821 | | -- Issue #160 Create local DevEnv aith appDependencyProbingPaths |
| 984 | +- Issue #160 Create local DevEnv with appDependencyProbingPaths |
822 | 985 | - Issue #156 Versioningstrategy 2 doesn't use 24h format |
823 | 986 | - Issue #155 Initial Add existing app fails with "Cannot find path" |
824 | 987 | - Issue #152 Error when loading dependencies from releases |
|
0 commit comments