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