v9.1

Resilient Pull Request Status Check for large builds

The Pull Request Status Check action no longer fails on builds with more than one page of jobs (more than 100 jobs). The jobs API call now uses --slurp so multi-page responses are parsed as a single JSON array (previously gh api --paginate | ConvertFrom-Json failed with "Invalid JSON primitive" when more than one page was returned). The call is also retried, and requests a smaller page size, to tolerate the intermittent HTTP 502 responses that the GitHub jobs endpoint returns for large builds.

Use artifact manifest to pick .NET runtime for assembly probing

When compiling apps with the workspace compiler, AL-Go now reads the dotNetVersion from the BC artifact's manifest.json (copied into the compiler folder by BcContainerHelper) and selects an installed .NET runtime whose major version matches. This avoids version drift between the build agent's highest installed runtime and the platform the artifact was built against. If the manifest does not declare a dotNetVersion, or no installed runtime matches the required major, versioned .NET assembly probing paths are omitted (a warning is logged in the latter case).

New compiler folder hooks

Two new hooks are available for customizing the compiler folder creation process when workspace compilation is enabled:

• PreNewBcCompilerFolder.ps1 - Runs before New-BcCompilerFolder is called. Receives a [hashtable] $parameters argument containing the parameters that will be passed to New-BcCompilerFolder. The script can modify the hashtable in-place to customize the compiler folder creation (e.g., add a platformArtifactUrl to use a specific platform version).
• PostNewBcCompilerFolder.ps1 - Runs after the compiler folder is created. Receives [hashtable] $parameters and [string] $compilerFolder arguments.

Place these scripts in your project's .AL-Go folder to use them.

New AL-Go hooks (experimental)

AL-Go for GitHub now supports a new generic hook mechanism that is independent of BcContainerHelper. A new RunHook action invokes scripts placed in the project's .AL-Go folder at well-known extension points in the workflows. The first such extension point is BuildInitialize, which runs in the build workflow immediately after Read settings (so AL-Go settings are available as environment variables).

To use it, add a .AL-Go/BuildInitialize.ps1 script that accepts a [Hashtable] $parameters argument. If the script does not exist, the step is a silent no-op.

The hook mechanism is intended to gradually replace the BcContainerHelper-based Run-AlPipeline script overrides as AL-Go moves away from Run-AlPipeline. See Customizing AL-Go for GitHub for details and the list of supported hook names.

Experimental: the set of supported hook names, the parameters passed to hook scripts, the location and timing of hook invocations, and the names of the underlying action and helpers may all change in future versions. Anything you build on top of this first iteration may break in a later update.

Conditional settings now support workflow trigger events

ConditionalSettings now supports a triggers condition, allowing you to apply settings based on GITHUB_EVENT_NAME values such as push, pull_request, schedule, and workflow_dispatch.

Example:

"ConditionalSettings": [
  {
    "triggers": ["schedule", "workflow_dispatch"],
    "settings": {
      "additionalCountries": ["de", "us"]
    }
  }
]

Support for workspace compilation (Continued)

• Added support for upgrade tests and using previously released artifacts as baselines for appsourcecop.json
• Added support for BCPT app compilation with workspace compilation
• Added support for incremental builds (modifiedApps mode) with workspace compilation. Unmodified apps are downloaded from the baseline workflow run and excluded from workspace compilation, matching the behavior of the container-based path.

Optimized dependency artifact downloads for multi-project repositories

The DownloadProjectDependencies action now downloads only artifacts from dependency projects instead of all workflow artifacts. For repositories with many AL-Go projects, this reduces build runner bandwidth and speeds up the dependency download step.

Issues

• Issue 2276 - Mitigate intermittent artifact action failures caused by the runner Node Maglev issue by setting ACTIONS_RUNNER_DISABLE_NODE_MAGLEV on generated artifact download and upload steps.
• Issue 2277 Auto-exclude the copilot GitHub environment from CI/CD deployments. When the GitHub Copilot coding agent is enabled on a repository, GitHub auto-creates an environment named copilot. AL-Go now treats it the same way as github-pages and never attempts to deploy to it.
• Issue 2236 - GetDependencies buildMode prefix leaks across dependency iterations, causing incorrect artifact mask names when multiple appDependencyProbingPaths entries use different build modes
• Incremental builds (modifiedApps mode) now correctly identify unmodified apps for projects whose appFolders reference paths outside the project directory (e.g. using ../)
• Issue 2204 - Workspace compilation ignores vsixFile setting
• Issue 2211 - Cannot create a release if a project contains only test apps
• Issue 2214 - Workspace compilation not working with external dependencies
• Issue 2235 - Workspace compilation: only the first customCodeCops entry resolved when multiple relative paths were configured. Relative customCodeCops paths are now resolved against the project folder before being passed to the compiler.
• Issue 2265 - Creating a Performance Test App fails on Linux due to case-sensitive path lookup for the Performance Toolkit sample app
• Issue 2284 - GitHub App authentication fails with 401 (Unauthorized) on runners with minor clock drift. The JWT iat claim is now backdated by 60 seconds instead of 10, as recommended by GitHub, to tolerate runners whose clock runs slightly ahead of GitHub.

v9.0

Needs Context in Build job moved from environment variable to file

NeedsContext is currently available as an environment variable in the build step of AL-Go. In some cases on repos with a large amount of projects, it's possible for this variable to exceed the max size GitHub allows for such variables. To work around this issue, we now place the contents of NeedsContext in a json file, where NeedsContext is the path to that file.

If you have any custom processes that uses NeedsContext, those needs to be updated to now first read the contents of the json file. The structure of the json is identical to what was previously in the variable, so only extra step is to read the file.

Added support for workspace compilation

With v28 of Business Central, the ALTool now also provides the ability to compile workspaces of apps. This has the added advantage that the ALTool can compute the dependency graph for the apps in the workspace and compile apps in parallel (if possible). For AL-Go projects with large amounts of apps that can save a lot of time. If you want to try this out you can enable it via the following setting

  "workspaceCompilation": {
    "enabled": true
  }

By default apps are compiled sequentially but this can be changed via the parallelism property. This allows you to configure the maximum amount of parallel compilation processes. Set to 0 or -1 to use all available processors.

  "workspaceCompilation": {
    "enabled": true,
    "parallelism": 4
  }

Test Projects — split builds and tests for faster feedback

AL-Go now supports test projects: a new project type that separates test execution from compilation. A test project does not build any apps itself — instead it depends on one or more regular projects, installs the apps they produce, and runs tests against them.

This lets you re-run tests without waiting for a full recompilation, and makes it easy to organize large repositories where builds and test suites have different scopes or cadences.

Getting started

Add a projectsToTest setting to the project-level .AL-Go/settings.json of an empty project (no appFolders or testFolders):

{
  "projectsToTest": ["build/projects/MyProject"]
}

AL-Go will automatically:

• Resolve the dependency so the test project always builds after its target project(s).
• Install the Test Runner, Test Framework, and Test Libraries into the container.
• Run all tests from the installed test apps.

Key rules

• A test project must not contain buildable code (no appFolders, testFolders, or bcptTestFolders). AL-Go will fail with a clear error if it detects both projectsToTest and buildable folders.
• A test project cannot depend on another test project.
• You can target multiple projects: "projectsToTest": ["build/projects/ProjectA", "build/projects/ProjectB"].
• Use full project paths as they appear in the repository.

Improving error detection and build reliability when downloading project dependencies

The DownloadProjectDependencies action now downloads app files from URLs specified in the installApps and installTestApps settings upfront, rather than validating URLs at build time. This change provides:

• Earlier detection of inaccessible or misconfigured URLs
• Clearer error messages when secrets are missing or URLs are invalid
• Warnings for potential issues like duplicate filenames

Improve overall performance by postponing projects with no dependants

The time it takes to build projects can vary significantly depending on factors such as whether you are using Linux or Windows, Containers or CompilerFolders, and whether apps are being published or tests are being run.

By default, projects are built according to their dependency order. As soon as all dependencies for a project are satisfied, the project is added to the next layer of jobs.

The new setting postponeProjectInBuildOrder allows you to delay long running jobs (f.ex. test runs) with no dependants until the final layer of the build order. This can improve overall build performance by preventing subsequent layers from waiting on projects that take longer to complete but are not required for further dependencies.

Issues

• Attempt to start docker service in case it is not running
• NextMajor (v28) fails when downloading dependencies from NuGet-feed
• Issue 2084 Multiple artifacts failure if you re-run failed jobs after flaky tests
• Issue 2085 Projects that doesn't contain both Apps and TestApps are wrongly seen as not built.
• Issue 2086 Postpone jobs, which doesn't have any dependents to the end of the build order.
• Rework input handling of workflow 'Update AL-Go System Files' for trigger 'workflow_call'

New Settings

• postponeProjectInBuildOrder is a new project setting, which will (if set to true) cause the project to be postponed until the last build job when possible. If set on test projects, then all tests can be deferred until all builds have succeeded.

v8.3

Issues

• Issue 2107 Publish a specific build mode to an environment
• 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: ALGoEnvSettings

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.

v7.2

Removed functionality

As stated in AL-Go Deprecations, setting cleanModePreprocessorSymbols is no longer supported and will be ignored by AL-Go for GitHub.

Security

• Add top-level permissions for Increment Version Number workflow

Issues

• Issue 1697 Error in CheckForUpdates: "Internet Explorer engine is not available" when using self-hosted runners
• Issue 1685 HttpError: Resource not accessible by integration
• Issue 1757 Error when signing apps with key vault signing

Workflow input validation

Some workflow inputs are now validated early in order to avoid workflows to make modifications like creating a release, when we already should know that an error will occur later.

Test settings against a JSON schema

AL-Go for GitHub settings now has a schema. The following line is added at the beginning to any AL-Go settings files to utilize the schema:

"$schema": "https://raw.githubusercontent.com/microsoft/AL-Go-Actions/<version>/Actions/settings.schema.json"

Failing pull requests if new warnings are added

By setting failOn to 'newWarning', pull requests will fail if new warnings are introduced. This feature compares the warnings in the pull request build against those in the latest successful CI/CD build and fails if new warnings are detected.

AL-Go Telemetry

Now AL-Go telemetry also logs ActionDuration which makes it possible to track the duration of the different steps in the AL-Go workflows (e.g. RunPipeline or Sign)

v7.1

Issues

• Issue 1678 Test summary is showing too many status icons
• Issue 1640 AL1040 error due to app folder within the artifacts cache being incorrectly recognized as an app folder
• Issue 1630 Error when downloading a release, when the destination folder already exists.
• Issue 1540 and 1649 Apps with dependencies to Microsft__EXCLUDE_ apps fails deployment
• Issue 1547 Dependencies will be installed even if DependencyInstallMode is ignore, but dependencies will never be installed on production environments
• Issue 1654 GithubPackageContext does not work together with private trustedNuGetFeeds
• Issue 1627 AL-Go should throw an error or a warning if you create a release, which is older than the latest release
• Issue 1657 When no files modified on Git, deployment fails
• Issue 1530 Dependency Field Service Integration does not get published in container while Installing apps
• Issue 1644 Support for AppAuth when using a private Template repository from another organization
• Issue 1669 GitHub App authentication to download dependencies from private repositories
• Issue 1478 Rate Limit Exceeded when running Update AL-Go System files

v7.0

Issues

• Issue 1519 Submitting to AppSource WARNING: AuthContext.Scopes is .. should be
• Issue 1521 Dependencies not installed for multi project incremental PR build
• Issue 1522 Strange warnings in Deploy job post update to AL-Go 6.4
• BcContainerHelper settings were only read from .github/AL-Go-Settings.json, not allowing global settings in ALGoOrgSettings for TrustedNuGetFeeds, MemoryLimit and other things that should be possible to define globally
• Issue 1526 When updating AL-Go system files, the update process (creating a PR or directly pushing to the branch) fails when there is a file or directory in the repo with the same name as the branch that is to be updated
• Legacy code signing stopped working

Page Scripting visualizer

Page scripting tests have been available for AL-Go for GitHub for a while but required manual inspection of the Page scripting artifact to see the results. It is now possible to get a quick overview in the job summary section of a CICD build, similar to how regular and bcpt test results are displayed.

No new settings are required. Test results will automatically be displayed if tests are enabled via the existing setting pageScriptingTests.

Support for deploying to sandbox environments from a pull request

AL-Go for GitHub now supports deploying from a PR. When using the 'Publish To Environment' workflow, it is now possible to input 'PR_X' as the App version, where 'X' is the PR Id. This will deploy the artifacts from the latest PR build to the chosen environment, if that build is completed and successful.

All apps, which were not built by the PR build will be deployed from the last known good build. You can find a notification on the PR build explaining which build is used as the last known good build.

Note

When deploying a PR build to a sandbox environment, the app will get a special version number, which is: major.minor.maxint.run-number. This means that the sandbox environment likely needs to be deleted after the testing has ended.