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.

v6.4

Deprecations

• alwaysBuildAllProjects will be removed after October 1st 2025. Please set the onPull_Request property of the incrementalBuilds setting to false to force full builds in Pull Requests.
• <workflow>Schedule will be removed after October 1st 2025. The old setting, where the setting key was a combination of the workflow name and Schedule (dynamic setting key name) is deprecated. Instead you need to use a setting called workflowSchedule and either use Conditional Settings or place the setting in a workflow specific settings file.

Issues

• Issue 1433 Publish to Environment - DependencyInstallMode not found
• Issue 1440 Create Release fails due to recent changes to the AL-Go
• Issue 1330 CompilerFolder doesn't transfer installed Apps to NuGet resolution
• Issue 1268 Do not throw an un-understandable error during nuGet download
• Performance test sample code in 25.4 contains objects with ID 149201 and 149202, which are not renumbered
• Issue 798 Publish To Environment breaks CI/CD pipelines
• Issue 1182 Runs-on setting type is ambiguous - string or array
• Issue 1502 NuGet dependency version is always LatestMatching

New Workflow specific settings

• workflowSchedule - can be structure with a property named cron, which must be a valid crontab, defining the CRON schedule for when the specified workflow should run. Default is no scheduled runs, only manual triggers. Build your crontab string here: https://crontab.guru. You need to run the Update AL-Go System Files workflow for the schedule to take effect.
  Note: If you configure a WorkflowSchedule for the CI/CD workflow, AL-Go will stop triggering CICDs on push unless you have also added CICDPushBranches to your settings.
  Note also: If you define a schedule for Update AL-Go System Files, it uses direct Commit instead of creating a PR.
• workflowConcurrency - is used to control concurrency of workflows. Like with the workflowSchedule setting, this setting should be applied in workflow specific settings files or conditional settings. By default, all workflows allows for concurrency, except for the Create Release workflow. If you are using incremental builds in CI/CD it is also recommented to set WorkflowConcurrency to:
  [ "group: ${{ github.workflow }}-${{ github.ref }}", "cancel-in-progress: true" ]
  in order to cancel prior incremental builds on the same branch.
  Read more about workflow concurrency here.

New Repository Settings

• nuGetFeedSelectMode determines the select mode when finding Business Central app packages from NuGet feeds, based on the dependency version specified in app.json. Options are: Earliest for earliest version of the package, EarliestMatching for earliest version of the package also compatible with the Business Central version used, Exact for the exact version of the package, Latest for the latest version of the package, LatestMatching for the latest version of the package also compatible with the Business Central version used.
• deployTo<environment> now has two additional properties:
  • includeTestAppsInSandboxEnvironment, which deploys test apps and their dependencies to the specified sandbox environment if set to true. Deployment will fail if used on a Prod environment or if the test app has a dependency on Tests-TestLibraries. Default value is false.
  • excludeAppIds, which is an array of app ids which will be excluded from deployment. Default value is []
• incrementalBuilds - is a structure defining how you want AL-Go to handle incremental builds. When using incremental builds for a build, AL-Go will look for the latest successful build, newer than the defined retentionDays and only rebuild projects or apps (based on mode) which needs to be rebuilt. Properties in the structure includes:
  • onPush - set this property to true in order to enable incremental builds in CI/CD triggered by a merge/push event. Default is false.
  • onPull_Request - set this property to false in order to disable incremental builds in Pull Request workflows. Default is true.
  • onSchedule - set this property to true in order to enable incremental builds in CI/CD when running on a schedule. Default is false.
  • retentionDays - number of days a successful build is good (and can be used for incremental builds). Default is 30.
  • mode - defines the mode for incremental builds. Currently, two values are supported. Use modifiedProjects when you want to rebuild all apps in modified projects and depending projects or modifiedApps if you only want to rebuild modified apps and depending apps.

Note

The projects mentioned here are AL-Go projects in a multi-project repository. A repository can contain multiple projects and a project can contain multiple apps.

Run "Update AL-Go System Files" on multiple branches

Update AL-Go System Files has a new input to specify a list of branches to be updated in a single workflow run.
When running the workflow on a schedule, you can now also specify includeBranches in workflowSchedule setting, which allows you to update the specified branches. Read more at https://aka.ms/algosettings#workflowSchedule.

Note

When running "Update AL-Go System Files" on multiple branches, the template repository URL will be determined based on the branch the workflow runs on and it will be used for all of the specified branches.

Support for incremental builds

AL-Go for GitHub now supports incremental builds, which means that unchanged projects or apps will be reused from the previous good build. Read this to learn more.

Note

When using incremental builds it is recommended to also set workflowConcurrency as defined here.

Support for GitHub App authentication

AL-Go for GitHub now supports using a GitHub App specification as the GhTokenWorkflow secret for a more secure way of allowing repositories to run Update AL-Go System Files and other workflows which are creating commits and pull requests. See this description to learn how to use GitHub App authentication.

Support for embedded secrets in installApps and installTestApps settings

If your installApps or installTestApps are secure URL, containing a secret token, you can now use a GitHub secret specification as part of or as the full URL of apps to install. An example could be:

"installApps": [ "https://www.dropbox.com/${{SECRETNAME}}&dl=1" ]

Which would hide the secret part of your URL instead of exposing it in clear text.

v6.3

Deprecations

• cleanModePreprocessorSymbols will be removed after April 1st 2025. Use Conditional Settings instead, specifying buildModes and the preprocessorSymbols setting. Read this for more information.

Issues

• It is now possible to skip the modification of dependency version numbers when running the Increment Version number workflow or the Create Release workflow

New Repository Settings

• shortLivedArtifactsRetentionDays determines the number of days to keep short lived build artifacts (f.ex build artifacts from pull request builds, next minor or next major builds). 1 is default. 0 means use GitHub default.
• preProcessorSymbols is a list of preprocessor symbols to use when building the apps. This setting can be specified in workflow specific settings files or in conditional settings.

New Versioning Strategy

Setting versioning strategy to 3 will allow 3 segments of the version number to be defined in app.json and repoVersion. Only the 4th segment (Revision) will be defined by the GitHub run_number for the CI/CD workflow. Increment version number and Create Release now also supports the ability to set a third segment to the RepoVersion and appversion in app.json.

Change in published artifacts

When using useProjectDependencies in a multi-project repository, AL-Go for GitHub used to generate short lived build artifacts called thisBuild-<projectnaame>-<type>-.... This is no longer the case. Instead, normal build artifacts will be published and used by depending projects. The retention period for the short lived artifacts generated are controlled by a settings called shortLivedArtifactsRetentionDays.

Preprocessor symbols

It is now possible to define preprocessor symbols, which will be used when building your apps using the preProcessorSymbols setting. This setting can be specified in workflow specific settings file or it can be used in conditional settings.

v6.2

Issues

• Issue 1296 Make property "appFolders" optional
• Issue 1344 Experimental feature "git submodules" seems to be a breaking change
• Issue 1305 Extra telemetry Property RepositoryOwner and RepositoryName¨
• Add RunnerEnvironment to Telemetry
• Output a notice, not a warning, when there are no available updates for AL-Go for GitHub

New Repository Settings

• useGitSubmodules can be either true or recursive if you want to enable Git Submodules in your repository. If your Git submodules resides in a private repository, you need to create a secret called gitSubmodulesToken containing a PAT with access to the submodule repositories. Like with all other secrets, you can also create a setting called gitSubmodulesTokenSecretName and specify the name of another secret, with these permissions (f.ex. ghTokenWorkflow).
• commitOptions - is a structure defining how you want AL-Go to handle automated commits or pull requests coming from AL-Go (e.g. for Update AL-Go System Files). The structure contains the following properties
  • messageSuffix : A string you want to append to the end of commits/pull requests created by AL-Go. This can be useful if you are using the Azure Boards integration (or similar integration) to link commits to workitems.
  • pullRequestAutoMerge : A boolean defining whether you want AL-Go pull requests to be set to auto-complete. This will auto-complete the pull requests once all checks are green and all required reviewers have approved.
  • pullRequestLabels : A list of labels to add to the pull request. The labels need to be created in the repository before they can be applied.

Support for Git submodules

In v6.1 we added experimental support for Git submodules - this did however only work if the submodules was in a public repository. In this version, you can use the useGitSubmodules setting to control whether you want to use Git Submodules and the gitSubmodulesToken secret to allow permission to read these repositories.

v6.1

Issues

• Issue 1241 Increment Version Number might produce wrong app.json
• When auto discovering appFolders, testFolders and bcptTestFolders - if a BCPT Test app has a dependency to a test framework app, it is added to testFolders as well as bcptTestFolders and will cause a failure.

New Project Settings

• pageScriptingTests should be an array of page scripting test file specifications, relative to the AL-Go project. Examples of file specifications: recordings/my*.yml (for all yaml files in the recordings subfolder matching my*.yml), recordings (for all *.yml files in the recordings subfolder) or recordings/test.yml (for a single yml file)
• doNotRunPageScriptingTests can force the pipeline to NOT run the page scripting tests specified in pageScriptingTests. Note this setting can be set in a workflow specific settings file to only apply to that workflow
• restoreDatabases should be an array of events, indicating when you want to start with clean databases in the container. Possible events are: BeforeBcpTests, BeforePageScriptingTests, BeforeEachTestApp, BeforeEachBcptTestApp, BeforeEachPageScriptingTest

New Repository Settings

• trustedSigning is a structure defining Account, EndPoint and CertificateProfile if you want to use trusted signing. Note that your Azure_Credentials secret (Microsoft Entra ID App or Managed identity) still needs to provide access to your azure subscription and be assigned the Trusted Signing Certificate Profile Signer role in the Trusted Signing Account.
• deployTo<environment> now has an additional property called DependencyInstallMode, which determines how dependencies are deployed if GenerateDependencyArtifact is true. Default value is install to install dependencies if not already installed. Other values are ignore for ignoring dependencies, upgrade for upgrading dependencies if possible and forceUpgrade for force upgrading dependencies.

Support for Azure Trusted Signing

Read https://learn.microsoft.com/en-us/azure/trusted-signing/ for more information about Trusted Signing and how to set it up. After setting up your trusted signing account and certificate profile, you need to create a setting called trustedSigning for AL-Go to sign your apps using Azure Trusted Signing.

Support for Page Scripting Tests

Page Scripting tests are now supported as part of CI/CD. By specifying pageScriptingTests in your project settings file, AL-Go for GitHub will automatically run these page scripting tests as part of your CI/CD workflow, generating the following build artifacts:

• PageScriptingTestResults is a JUnit test results file with all results combined.
• PageScriptingTestResultDetails are the detailed test results (including videos) when any of the page scripting tests have failures. If the page scripting tests succeed - the details are not published.

Experimental support for Git submodule

Git submodule is now supported as part of CI/CD on your project.

v6.0

Issues

• Issue 1184 Publish to Environment fails on 'Permission Denied'
• AL Language extension in 25.0 doesn't contain the linux executable, use dotnet to invoke the dll instead.

New Settings

• deliverTo<deliverytarget> now has an additional property called ContinuousDelivery, indicating whether or not to run continuous delivery to this deliveryTarget. Default is true.
• trustMicrosoftNuGetFeeds Unless this setting is set to false, AL-Go for GitHub will trust the NuGet feeds provided by Microsoft. The feeds provided by Microsoft contains all Microsoft apps, all Microsoft symbols and symbols for all AppSource apps.
• trustedNuGetFeeds - can be an array of NuGet feed specifications, which AL-Go for GitHub will use for dependency resolution. Every feed specification must include a URL property and can optionally include a few other properties:
  • url - The URL of the feed (examples: https://pkgs.dev.azure.com/myorg/apps/\_packaging/myrepo/nuget/v3/index.json or https://nuget.pkg.github.com/mygithuborg/index.json").
  • patterns - AL-Go for GitHub will only trust packages, where the ID matches this pattern. Default is all packages (*).
  • fingerprints - If specified, AL-Go for GitHub will only trust packages signed with a certificate with a fingerprint matching one of the fingerprints in this array.
  • authTokenSecret - If the NuGet feed specified by URL is private, the authTokenSecret must be the name of a secret containing the authentication token with permissions to search and read packages from the NuGet feed.

Support for delivering to GitHub Packages and NuGet

With this release the implementation for delivering to NuGet packages (by adding the NuGetContext secret), is similar to the functionality behind delivering to GitHub packages and the implementation is no longer in preview.

Allow GitHubRunner and GitHubRunnerShell as project settings

Previously, AL-Go required the GitHubRunner and GitHubRunnerShell settings to be set on repository level. This has now been changed such that they can be set on project level.

v5.3

Issues

• Issue 1105 Increment Version Number - repoVersion in .github/AL-Go-Settings.json is not updated
• Issue 1073 Publish to AppSource - Automated validation: failure
• Issue 980 Allow Scope to be PTE in continuousDeployment for PTE extensions in Sandbox (enhancement request)
• Issue 1079 AppSource App deployment failes with PerTenantExtensionCop Error PTE0001 and PTE0002
• Issue 866 Accessing GitHub Environment Variables in DeployToCustom Scenarios for PowerShell Scripts
• Issue 1083 SyncMode for custom deployments?
• Issue 1109 Why filter deployment settings?
• Fix issue with github ref when running reusable workflows
• Issue 1098 Support for specifying the name of the AZURE_CREDENTIALS secret by adding a AZURE_CREDENTIALSSecretName setting
• Fix placeholder syntax for git ref in PullRequestHandler.yaml
• Issue 1164 Getting secrets from Azure key vault fails in Preview

Dependencies to PowerShell modules

AL-Go for GitHub relies on specific PowerShell modules, and the minimum versions required for these modules are tracked in Packages.json file. Should the installed modules on the GitHub runner not meet these minimum requirements, the necessary modules will be installed as needed.

Support managed identities and federated credentials

All authentication context secrets now supports managed identities and federated credentials. See more here. Furthermore, you can now use https://aka.ms/algosecrets#authcontext to learn more about the formatting of that secret.

Business Central Performance Toolkit Test Result Viewer

In the summary after a Test Run, you now also have the result of performance tests.

Support Ubuntu runners for all AL-Go workflows

Previously, the workflows "Update AL-Go System Files" and "TroubleShooting" were hardcoded to always run on windows-latest to prevent deadlocks and security issues.
From now on, ubuntu-lates will also be allowed for these mission critical workflows, when changing the runs-on setting. Additionally, only the value pwsh for shell setting is allowed when using ubuntu-latest runners.

Updated AL-Go telemetry

AL-Go for GitHub now includes a new telemetry module. For detailed information on how to enable or disable telemetry and to see what data AL-Go logs, check out this article.

New Settings

• deployTo<environmentName>: is not really new, but has a new property:

  • Scope = specifies the scope of the deployment: Dev, PTE. If not specified, AL-Go for GitHub will always use the Dev Scope for AppSource Apps, but also for PTEs when deploying to sandbox environments when impersonation (refreshtoken) is used for authentication.
  • BuildMode = specifies which buildMode to use for the deployment. Default is to use the Default buildMode.
  • <custom> = custom properties are now supported and will be transferred to a custom deployment script in the hashtable.

• bcptThresholds is a JSON object with properties for the default thresholds for the Business Central Performance Toolkit

  • DurationWarning - a warning is issued if the duration of a bcpt test degrades more than this percentage (default 10)
  • DurationError - an error is issued if the duration of a bcpt test degrades more than this percentage (default 25)
  • NumberOfSqlStmtsWarning - a warning is issued if the number of SQL statements from a bcpt test increases more than this percentage (default 5)
  • NumberOfSqlStmtsError - an error is issued if the number of SQL statements from a bcpt test increases more than this percentage (default 10)

Note

Duration thresholds are subject to varying results depending on the performance of the agent running the tests. Number of SQL statements executed by a test is often the most reliable indicator of performance degredation.

v5.2

Issues

• Issue 1084 Automatic updates for AL-Go are failing when main branch requires Pull Request

New Settings

• PowerPlatformSolutionFolder: Contains the name of the folder containing a PowerPlatform Solution (only one)
• DeployTo<environment> now has two additional properties companyId is the Company Id from Business Central (for PowerPlatform connection) and ppEnvironmentUrl is the Url of the PowerPlatform environment to deploy to.

New Actions

• BuildPowerPlatform: to build a PowerPlatform Solution
• DeployPowerPlatform: to deploy a PowerPlatform Solution
• PullPowerPlatformChanges: to pull changes made in PowerPlatform studio into the repository
• ReadPowerPlatformSettings: to read settings and secrets for PowerPlatform deployment
• GetArtifactsForDeployment: originally code from deploy.ps1 to retrieve artifacts for releases or builds - now as an action to read apps into a folder.

New Workflows

• Pull PowerPlatform Changes for pulling changes from your PowerPlatform development environment into your AL-Go for GitHub repository
• Push PowerPlatform Changes for pushing changes from your AL-Go for GitHub repository to your PowerPlatform development environment

Note

PowerPlatform workflows are only available in the PTE template and will be removed if no PowerPlatformSolutionFolder is defined in settings.

New Scenarios (Documentation)

• Connect your GitHub repository to Power Platform
• How to set up Service Principal for Power Platform
• Try one of the Business Central and Power Platform samples
• Publish To AppSource

Note

PowerPlatform functionality are only available in the PTE template.

v5.1

Issues

• Issue 1019 CI/CD Workflow still being scheduled after it was disabled
• Issue 1021 Error during Create Online Development Environment action
• Issue 1022 Error querying artifacts: No such host is known. (bcartifacts-exdbf9fwegejdqak.blob.core.windows.net:443)
• Issue 922 Deploy Reference Documentation (ALDoc) failed with custom
• ContainerName used during build was invalid if project names contained special characters
• Issue 1009 by adding a includeDependencies property in DeliverToAppSource
• Issue 997 'Deliver to AppSource' action fails for projects containing a space
• Issue 987 Resource not accessible by integration when creating release from specific version
• Issue 979 Publish to AppSource Documentation
• Issue 1018 Artifact setting - possibility to read version from app.json
• Issue 1008 Allow PullRequestHandler to use ubuntu or self hosted runners for all jobs except for pregateCheck
• Issue 962 Finer control of "shell"-property
• Issue 1041 Harden the version comparison when incrementing version number
• Issue 1042 Downloading artifacts from GitHub doesn't work with branch names which include forward slashes

Better artifact selection

The artifact setting in your project settings file can now contain a * instead of the version number. This means that AL-Go for GitHub will determine the application dependency for your projects together with the applicationDependency setting and determine which Business Central version is needed for the project.

• "artifact": "//*//latest" will give you the latest Business Central version, higher than your application dependency and with the same major.minor as your application dependency.
• "artifact": "//*//first" will give you the first Business Central version, higher than your application dependency and with the same major.minor as your application dependency.

New Settings

• deliverToAppSource: a JSON object containing the following properties
  • productId must be the product Id from partner Center.
  • mainAppFolder specifies the appFolder of the main app if you have multiple apps in the same project.
  • continuousDelivery can be set to true to enable continuous delivery of every successful build to AppSource Validation. Note that the app will only be in preview in AppSource and you will need to manually press GO LIVE in order for the app to be promoted to production.
  • includeDependencies can be set to an array of file names (incl. wildcards) which are the names of the dependencies to include in the AppSource submission. Note that you need to set generateDependencyArtifact in the project settings file to true in order to include dependencies.
• Add shell as a property under DeployTo structure

Deprecated Settings

• appSourceContinuousDelivery is moved to the deliverToAppSource structure
• appSourceMainAppFolder is moved to the deliverToAppSource structure
• appSourceProductId is moved to the deliverToAppSource structure

New parameter -clean on localdevenv and clouddevenv

Adding -clean when running localdevenv or clouddevenv will create a clean development environment without compiling and publishing your apps.

v5.0

Issues

• Issue 940 Publish to Environment is broken when specifying projects to publish
• Issue 994 CI/CD ignores Deploy to GitHub Pages in private repositories

New Settings

• UpdateALGoSystemFilesEnvironment: The name of the environment that is referenced in job UpdateALGoSystemFiles in the Update AL-Go System Files workflow. See jobs.<job_id>.environment for more information. Currently, only setting the environment name is supported.

Issues

• Support release branches that start with releases/
• Issue 870 Improve Error Handling when CLI is missing
• Issue 889 CreateRelease and IncrementVersionNumber workflow did not handle wild characters in appFolders, testFolders or bcptTestFolders settings.
• Issue 973 Prerelease is not used for deployment

Build modes

AL-Go ships with Default, Translated and Clean mode out of the box. Now you can also define custom build modes in addition to the ones shipped with AL-Go. This allows you to define your own build modes, which can be used to build your apps in different ways. By default, a custom build mode will build the apps similarly to the Default mode but this behavior can be overridden in e.g. script overrides in your repository.