|
| 1 | +## v8.2 |
| 2 | + |
| 3 | +### Issues |
| 4 | + |
| 5 | +- Issue 2095 DeliverToAppSource.ProductId needs to be specified (Library app) |
| 6 | +- Issue 2082 Sign action no longer fails when repository is empty or no artifacts are generated |
| 7 | +- Issue 2078 Workflows run since January 14th '26 have space before CI/CD removed |
| 8 | +- Issue 2070 Support public GitHub Packages feeds without requiring a Personal Access Token (PAT) |
| 9 | +- Issue 2004 PublishToAppSource workflow publishes multi-app repos in alphabetical order instead of dependency order |
| 10 | +- Issue 2045 DateTime parsing fails on non-US locale runners in WorkflowPostProcess.ps1 |
| 11 | +- Issue 2055 When using versioningStrategy 3+16, you get an error when building |
| 12 | +- Issue 2094 PR into release branch gets wrong previous release |
| 13 | +- AL-Go repositories with large amounts of projects may run into issues with too large environment variables |
| 14 | +- Discussion 1855 Add trigger 'workflow_call' to workflow 'Update AL-Go System Files' for reusability |
| 15 | +- Issue 2050 Publish To Environment creates mistyped environment |
| 16 | + |
| 17 | +### Publish To Environment no longer creates unknown environments by default |
| 18 | + |
| 19 | +Previously, when running the "Publish To Environment" workflow with an environment name that doesn't exist in GitHub or AL-Go settings, the workflow would automatically create a new GitHub environment. This could lead to problems when environment names were mistyped, as the bogus environment would then cause subsequent CI/CD workflows to fail. |
| 20 | + |
| 21 | +Now, the workflow will fail with a clear error message if the specified environment doesn't exist. If you intentionally want to deploy to a new environment that hasn't been configured yet, you can check the **Create environment if it does not exist** checkbox when running the workflow. |
| 22 | + |
| 23 | +### Set default values for workflow inputs |
| 24 | + |
| 25 | +The `workflowDefaultInputs` setting now also applies to `workflow_call` inputs when an input with the same name exists for `workflow_dispatch`. |
| 26 | +This ensures consistent default values across both manual workflow runs and reusable workflow calls. |
| 27 | + |
| 28 | +Read more at [workflowDefaultInputs](https://aka.ms/algosettings#workflowDefaultInputs). |
| 29 | + |
| 30 | +### Merge queue support |
| 31 | + |
| 32 | +AL-Go now supports GitHub's merge queue feature out of the box! The `merge_group` trigger has been added to the Pull Request Build workflow, enabling seamless integration with merge queues. When you have the merge queue feature enabled in your repo, multiple PRs will automatically be validated together. Read more about merge queues [here](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-a-merge-queue). |
| 33 | + |
| 34 | +> [!WARNING] |
| 35 | +> If you rely on a custom workflow for merge queue validation, you may need to adjust your setup to avoid duplicate builds. |
| 36 | +
|
| 37 | +### AL-Go Telemetry updates |
| 38 | + |
| 39 | +AL-Go telemetry now includes test results so you can more easily see how many AL tests, Page Scripting tests and BCPT tests ran in your workflows across all your repositories. Documentation for this can be found on [this article](https://github.com/microsoft/AL-Go/blob/main/Scenarios/EnablingTelemetry.md) on enabling telemetry. |
| 40 | + |
1 | 41 | ## v8.1 |
2 | 42 |
|
3 | 43 | ### Custom AL-Go files |
|
0 commit comments