Open
Conversation
Contributor
There was a problem hiding this comment.
Pull request overview
Adds opt-in “test isolation” support to AL-Go so a single test stage can be partitioned across multiple test runners (to satisfy mixed RequiredTestIsolation requirements) while preserving existing Run-AlPipeline behaviors like disabled tests handling and result aggregation.
Changes:
- Introduces new
testIsolationsetting (defaults, schema validation, and documentation). - Adds a
RunTestsInBcContaineroverride hook inRunPipelinethat runs partitions + a default “everything else” pass. - Adds Pester coverage for the new partitioning scriptblock and settings schema shape/validation.
Reviewed changes
Copilot reviewed 10 out of 10 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| Tests/TestIsolation.Test.ps1 | New Pester tests covering partition invocation behavior, negated default filter construction, parameter forwarding, and failure aggregation. |
| Tests/ReadSettings.Test.ps1 | Extends schema tests to cover testIsolation defaults and schema validation rules. |
| Scenarios/settings.md | Documents the new testIsolation setting in the settings reference table. |
| Scenarios/TestIsolation.md | Adds a dedicated scenario doc describing configuration, semantics, compatibility, and edge cases. |
| RELEASENOTES.md | Adds release notes entry describing the new opt-in test isolation partitioning capability. |
| README.md | Links the new Test Isolation scenario from the main scenarios list. |
| Actions/RunPipeline/RunPipeline.ps1 | Wires testIsolation into Run-AlPipeline by injecting a partitioning RunTestsInBcContainer scriptblock and emitting telemetry. |
| Actions/.Modules/settings.schema.json | Adds testIsolation schema (object shape, required keys, and partition entry validation). |
| Actions/.Modules/TestIsolation.psm1 | New module that builds the partitioning scriptblock and computes the negated default codeunit-range filter. |
| Actions/.Modules/ReadSettings.psm1 | Adds testIsolation to default settings so it participates in the normal settings merge+validation pipeline. |
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Add Test Isolation support
Why
BC runtime 16 (2025 W2) added the
RequiredTestIsolationproperty on test codeunits. The standard BC test runner has a single, fixedTestIsolationvalue, so any project that mixes codeunits with different isolation requirements cannot run them all under one runner, those tests get excluded from CI.AL-Go today makes one blanket
Run-TestsInBcContainercall per test app under the default runner. Test codeunits that need a non-default runner (e.g.TestIsolation = Disabledfor long-running integration tests that must not roll back) have to be placed indisabledtests.jsonand run manually, losing CI coverage.This contribution closes that gap.
Discussion reference
#1565
How
A new opt-in
testIsolationsetting lets projects partition the test stage:When
enabled,RunPipelineinstalls a-RunTestsInBcContainerscriptblock intoRun-AlPipelinethat, per test app:Run-TestsInBcContaineronce per entry inpartitions, with-testRunnerCodeunitIdand-testCodeunitRangeset from the entry.defaultRunnerCodeunitIdwhose-testCodeunitRangeis the negation of every explicit partition's filter, so codeunits not in any partition run exactly once under the default runner.The scriptblock forwards all other Run-AlPipeline parameters verbatim, so
disabledTests.jsonhandling, JUnit result appending, container lifecycle, anduseCompilerFoldersupport continue to work unchanged. Feature is strictly additive and off by default.Validation
disabledtests.jsonfor lack of aTestIsolation = Disabledrunner now execute successfully under standard BCApps runner130451, while the remaining test codeunits (99201–99203) run under the default runner in the same build — proving both the partition call and the negated-filter fallback work against real BcContainerHelper.