[main@69555c0] Update AL-Go System Files from microsoft/AL-Go-PTE@preview - 318a202

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

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.

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.