Disable clean test codeunit execution

[Alexander Holstrup (aholstrup1)]

What & why

Change only .github/AL-Go-Settings.json: set enableCleanTestCodeunitExecution from true to false.

This is a narrow mitigation/coverage rollback for comparison with the full-revert draft #12514, not a fix for the underlying Expense API null reference. It is an independent alternative based on main, not stacked on or dependent on that PR. Unlike the 21-file full revert, this preserves the production approver-filter fix, test fixes, clean-execution infrastructure, and existing test exclusion manifests introduced or retained by #12325 (enabling commit 3f357d6c93edab81eab2437909d8dab17637ba0d).

The investigation of workflow run 37598783939 identified 22 failed jobs: 19 IntegrationTests jobs with Expense API GET HTTP 500/null-reference failures, two lost self-hosted runners (AT IntegrationTests and GB UncategorizedTests), and the downstream PR Status Check. The failing Expense methods are EmployeesAPICanFilterExpenseUsers (CU148315), CapabilitiesProjectsEnabledViaAPI (CU148318), and ActivityLogEntryIsExposedThroughReadOnlyAPI (CU148343); all require RequiredTestIsolation=Disabled. Italy also has ten Avalara E2E shipment-number-series S-SHPT date failures.

The setting gates Get-RequiredDisabledWorkItems discovery and extra clean execution in ParallelTestExecution.psm1. Ordinary typed selection uses None|Codeunit, while the automatic Disabled fallback is UnitTest-only. Disabling the setting is therefore expected to suppress these Expense integration tests rather than make them pass.

Linked work

No approved GitHub issue or ADO work item was supplied; no closing reference is claimed. The approved-issue requirement remains outstanding before this draft is ready for review.

Comparison alternative: #12514. Original enabling PR: #12325. Failure evidence: workflow run 37598783939.

How I validated this

• I read the full diff and it contains only changes I intended.
• I built the affected app(s) locally with no new analyzer warnings.
• I ran the change in Business Central and confirmed it behaves as expected.
• I added or updated tests for the new behavior, or explained below why none are needed.

What I tested and the outcome (required — be specific: scenarios, commands, screenshots for UI changes)

• Get-Content .github\AL-Go-Settings.json -Raw | ConvertFrom-Json — passed; separately asserted enableCleanTestCodeunitExecution is Boolean false and that the file differs from HEAD only by the requested true-to-false replacement.
• git -c core.longpaths=true diff --check — passed.
• git --no-pager diff -- .github\AL-Go-Settings.json and git -c core.longpaths=true diff --stat — reviewed; exactly one file, one insertion, one deletion.
• Import-Module Pester -RequiredVersion 5.7.1; $result = Invoke-Pester -Path .\build\scripts\tests\ParallelTestExecution.Test.ps1 -PassThru -Output Minimal; if ($result.FailedCount -gt 0 -or $result.PassedCount -eq 0) { throw 'Pester validation failed' }; $result | Select-Object Result,PassedCount,FailedCount,SkippedCount — passed: 87 passed, 0 failed, 0 skipped. This is mocked orchestration coverage, not a live BC integration run.
• No tests added: this changes only an existing feature flag, with existing orchestration tests covering disabled clean execution. No AL app build or live Business Central execution was performed; CI comparison is still needed.

Risk & compatibility

This is a repository-wide coverage rollback: other tests dependent on the extra clean execution lane will also stop running through that lane. Existing ordinary execution and exclusion manifests remain unchanged. It does not repair the Expense API HTTP 500/null-reference defect and does not resolve lost runners or Italy's Avalara shipment-number-series failures; a fully green run is not promised. No production AL, schema, permission, or upgrade changes are included. Keep as a draft for comparison with the full-revert alternative; neither PR is merged by this change.

[github-actions]

Could not find a linked work item. Please link one in either of these ways: (1) link an ADO work item using the pattern 'AB#' followed by the work item number - you may use the 'Fixes' keyword to automatically resolve it when the pull request is merged, e.g. 'Fixes AB#1234'; or (2) link a GitHub issue of type 'Task' using the pattern 'Fixes #' followed by the issue number, e.g. 'Fixes #1234'.