You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: .github/RELEASENOTES.copy.md
+72Lines changed: 72 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,10 +2,82 @@
2
2
3
3
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.
4
4
5
+
### Added support for workspace compilation
6
+
7
+
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
8
+
9
+
```json
10
+
"workspaceCompilation": {
11
+
"enabled": true
12
+
}
13
+
```
14
+
15
+
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.
16
+
17
+
```json
18
+
"workspaceCompilation": {
19
+
"enabled": true,
20
+
"parallelism": 4
21
+
}
22
+
```
23
+
24
+
### Test Projects — split builds and tests for faster feedback
25
+
26
+
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.
27
+
28
+
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.
29
+
30
+
**Getting started**
31
+
32
+
Add a `projectsToTest` setting to the project-level `.AL-Go/settings.json` of an empty project (no `appFolders` or `testFolders`):
33
+
34
+
```json
35
+
{
36
+
"projectsToTest": ["build/projects/MyProject"]
37
+
}
38
+
```
39
+
40
+
AL-Go will automatically:
41
+
42
+
- Resolve the dependency so the test project always builds after its target project(s).
43
+
- Install the Test Runner, Test Framework, and Test Libraries into the container.
44
+
- Run all tests from the installed test apps.
45
+
46
+
**Key rules**
47
+
48
+
- 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.
49
+
- A test project cannot depend on another test project.
50
+
- You can target multiple projects: `"projectsToTest": ["build/projects/ProjectA", "build/projects/ProjectB"]`.
51
+
- Use full project paths as they appear in the repository.
52
+
53
+
### Improving error detection and build reliability when downloading project dependencies
54
+
55
+
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:
56
+
57
+
- Earlier detection of inaccessible or misconfigured URLs
58
+
- Clearer error messages when secrets are missing or URLs are invalid
59
+
- Warnings for potential issues like duplicate filenames
60
+
61
+
### Improve overall performance by postponing projects with no dependants
62
+
63
+
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.
64
+
65
+
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.
66
+
67
+
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.
68
+
5
69
### Issues
6
70
7
71
- Attempt to start docker service in case it is not running
8
72
- NextMajor (v28) fails when downloading dependencies from NuGet-feed
73
+
- Issue 2084 Multiple artifacts failure if you re-run failed jobs after flaky tests
74
+
- Issue 2085 Projects that doesn't contain both Apps and TestApps are wrongly seen as not built.
75
+
- Issue 2086 Postpone jobs, which doesn't have any dependents to the end of the build order.
76
+
- Rework input handling of workflow 'Update AL-Go System Files' for trigger 'workflow_call'
77
+
78
+
### New Settings
79
+
80
+
-`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.
0 commit comments