[releases/27.1@eb325b9] Update AL-Go System Files from microsoft/AL-Go-PTE@preview - 87ad9f9 / Related to AB#539394

[business-central-bot]

preview

Note that when using the preview version of AL-Go for GitHub, we recommend you Update your AL-Go system files, as soon as possible when informed that an update is available.

Issues

• Issue 1915 CICD fails on releases/26.x branch - '26.x' cannot be recognized as a semantic version string

The default pull request trigger is changing

AL-Go for GitHub is transitioning from the pull_request_target trigger to the more secure pull_request trigger. This is a step we are taking to make AL-Go for GitHub more secure by default. If you are used to working from branches within the repository you may not notice any difference. If you get pull requests from forks, those pull requests will no longer be able to access secrets. If that is blocking for your repository, you will need to update your settings to use the pull_request_target trigger.

How do I revert back to pull_request_target?

Add the following setting to one of your settings files and run the Update AL-Go System Files workflow:

  "pullRequestTrigger": "pull_request_target"

v8.2

Issues

• Issue 2095 DeliverToAppSource.ProductId needs to be specified (Library app)
• Issue 2082 Sign action no longer fails when repository is empty or no artifacts are generated
• Issue 2078 Workflows run since January 14th '26 have space before CI/CD removed
• Issue 2070 Support public GitHub Packages feeds without requiring a Personal Access Token (PAT)
• Issue 2004 PublishToAppSource workflow publishes multi-app repos in alphabetical order instead of dependency order
• Issue 2045 DateTime parsing fails on non-US locale runners in WorkflowPostProcess.ps1
• Issue 2055 When using versioningStrategy 3+16, you get an error when building
• Issue 2094 PR into release branch gets wrong previous release
• AL-Go repositories with large amounts of projects may run into issues with too large environment variables
• Discussion 1855 Add trigger 'workflow_call' to workflow 'Update AL-Go System Files' for reusability
• Issue 2050 Publish To Environment creates mistyped environment

Publish To Environment no longer creates unknown environments by default

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.

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.

Set default values for workflow inputs

The workflowDefaultInputs setting now also applies to workflow_call inputs when an input with the same name exists for workflow_dispatch.
This ensures consistent default values across both manual workflow runs and reusable workflow calls.

Read more at workflowDefaultInputs.

Merge queue support

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.

Warning

If you rely on a custom workflow for merge queue validation, you may need to adjust your setup to avoid duplicate builds.

AL-Go Telemetry updates

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 on enabling telemetry.

v8.1

Custom AL-Go files

AL-Go for GitHub now supports updating files from your custom templates via the new customALGoFiles setting. Read more at customALGoFiles.

Set default values for workflow inputs

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.

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.
The default values must match the input types (boolean, number, string, or choice) defined in the workflow YAML files.

Example configuration:

{
  "workflowDefaultInputs": [
    { "name": "directCommit", "value": true },
    { "name": "useGhTokenWorkflow", "value": true }
  ]
}

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 to apply defaults only to specific workflows, branches, or other conditions.

Example using conditional settings to target specific workflows:

{
  "conditionalSettings": [
    {
      "workflows": ["Create Release"],
      "settings": {
        "workflowDefaultInputs": [
          { "name": "directCommit", "value": true },
          { "name": "releaseType", "value": "Prerelease" }
        ]
      }
    }
  ]
}

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.

Read more at workflowDefaultInputs.

Issues

• Issue 2039 Error when deploy to environment: NewTemporaryFolder is not recognized
• Issue 1961 KeyVault access in PR pipeline
• Discussion 1911 Add support for reportSuppressedDiagnostics
• Discussion 1968 Parameter for settings passed to CreateDevEnv
• Issue 1945 Deploy Reference Documentation fails for CI/CD
• Use Runner_Temp instead of GetTempFolder whenever possible
• Issue 2016 Running Update AL-Go system files with branches wildcard * tries to update origin
• Issue 1960 Deploy Reference Documentation fails
• Discussion 1952 Set default values on workflow_dispatch input

Deprecations

• unusedALGoSystemFiles will be removed after October 1st 2026. Please use customALGoFiles.filesToExclude instead.

v8.0

Mechanism to overwrite complex settings type

By default, AL-Go merges settings from various places (see settings levels). Basic setting types such as string and integer are overwritten, but settings with complex types such as array and object are merged.

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

AL Code Analysis tracked in GitHub

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.

Enable this feature by using the new setting trackALAlertsInGithub. This setting must be enabled at the repo level, but can optionally be disabled per project.

Please note that some automated features are premium and require the use of GitHub Code Security

Issues

• Discussion 1885 Conditional settings for CI/CD are not applied
• Discussion 1899 Remove optional properties from "required" list in settings.schema.json
• 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)
• Issue 1926 Deployment fails when using build modes
• Issue 1898 GetDependencies in localDevEnv does not fallback to github token
• Issue 1947 Project settings are ignored when loading bccontainerhelper
• Issue 1937 trackALAlertsInGitHub is failing in preview
• DeployTo settings from environment-specific AL-Go settings are not applied when deploying
• ReadSettings action outputs too much information that is mainly used for debugging

v7.3

Configurable merge method for pull request auto-merge

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.

Example

{
  "commitOptions": {
    "pullRequestAutoMerge": true,
    "pullRequestMergeMethod": "merge"
  }
}

AL-Go Telemetry

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.

Support for AL-Go settings as GitHub environment variable: ALGoEnvironmentSettings

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.

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. Settings defined in this variable will take priority over any setting defined in AL-Go repo, org or settings files.

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:

{
  DeployToProduction {
    "Branches": [
        "*"
    ],
    "includeTestAppsInSandboxEnvironment": false,
    "excludeAppIds": [ 1234 ]
  }
}

Please note, that due to certain security limitations, the properties runs-on, shell and ContinousDeployment of the DeployTo setting will NOT 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.

Issues

• Issue 1770 Wrong type of projects setting in settings schema
• Issue 1787 Publish to Environment from PR fails in private repos
• Issue 1722 Check if apps are already installed on a higher version before deploying
• Issue 1774 Increment Version Number with +0.1 can increment some version numbers twice
• Issue 1837 Deployment from PR builds fail if PR branch name includes forward slashes (e.g., feature/branch-name).
• Issue 1852 Page Scripting Tests are not added to build summary
• Issue 1829 Added custom jobs cannot be removed
• Idea 1856 Include workflow name as input for action ReadSetting

Additional debug logging functionality

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.

Add custom jobs to AL-Go workflows

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 for details.

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.

Support for Custom AL-Go template repositories

Create an AL-Go for GitHub repository based on https://aka.ms/algopte or 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 for details.

Note

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.

Related to AB#539394