[releases/25.x] Update AL-Go System Files from microsoft/AL-Go-PTE@preview - 4c9ea6f8e445c270e93ff18ec7cf07153256ec8f / Related to AB#539394

[bcbuild-github-agent]

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.

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

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

• 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.

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.

Related to AB#539394