Reset legacy test container DB in bulk instead of per-app uninstall loop

[Alexander Holstrup (aholstrup1)]

What & why

Legacy test jobs spend ~19-24 min of every container setup uninstalling and unpublishing the ~150 apps pre-installed in the BC image, one at a time, before AL-Go publishes the repo-built apps. The bottleneck is not schema work but per-app container-session overhead (~8s each round-trip), so it cannot be optimized by tuning the loop.

This replaces that loop with a single bulk operation: drop and recreate the application database, which removes every app at once, then rebuild only what AL-Go needs to take over.

Approach

New build/scripts/ResetBcContainerDatabase.psm1 exposes Reset-BcContainerApplicationDatabase, which:

• extracts the System Application from the container's own published copy first (BCApps overrides the platform artifact, which strips System App from disk, so this is the only source that survives),
• drops the app + tenant databases and creates an empty application database,
• re-imports the developer license (dropped with the DB), re-publishes System App (required for the SUPER permission set under UsePermissionSetsFromExtensions=true), and creates a SUPER user,
• restores multitenancy with a fresh, empty default tenant.

build/scripts/NewBcContainer.ps1 resolves the license deterministically from the artifact manifest and calls the reset. The existing removal loop stays but now runs over the single remaining System App.

Linked work

Fixes AB#646519

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

• Ran the reset end to end on a fresh multitenant BC 28 container locally: full reset in ~3.6 min, ending with the default tenant Operational, System App installed, Multitenant=True, and AllowAppDatabaseWrite=True.
• Validated in CI (run 30431641630): the reset succeeds and 15,020 tests run with no read-only / DemoTool / Media-insert errors. On the same DE LegacyTestsBucket2 job, container creation dropped from 24.3 min to 9.8 min (about -14.5 min, -60%). Scaled across 110 self-hosted jobs that is roughly -27 compute-hours per full build.
• Two issues found and fixed during local validation: the default tenant must be mounted with -allowAppDatabaseWrite (otherwise demo-data generation cannot insert Media records), and the in-container database scriptblocks must run under Windows PowerShell 5.1 (-usePwsh $false) because the NAV management cmdlets / Invoke-Sqlcmd hit .NET assembly-load conflicts under the container's pwsh7.
• No AL tests added: this is a CI/build-infrastructure change to PowerShell setup scripts, not product code.

Note: the remaining known-flaky test failures in this run are pre-existing and are tolerated on real PR builds (the Test Tolerance feature only applies when GITHUB_EVENT_NAME == 'pull_request', not on the workflow_dispatch run used above).

Risk & compatibility

• Only affects the CI container-setup path (build/scripts); no product code changes.
• Behavior depends on multitenant containers and on the developer license shipping inside the BC artifact (resolved via manifest.json). The reset throws early if the System App is not published or the license is missing, so a misconfigured container fails fast rather than silently.
• End state for AL-Go is unchanged (empty writable default tenant, no repo apps published yet); the downstream publish/test phases are untouched.

[github-actions]

$\textbf{🟡\ Medium\ Severity\ —\ Agent}$

In Clear-BcApplicationDatabase, $dbproperties (the SELECT of applicationfamily from the soon-to-be-dropped database) is used unchecked when rebuilding the new database: SET [applicationfamily] = '$($dbproperties.applicationfamily)'. If the SELECT returns no row (e.g. the query fails, the table/column differs across platform versions, or $databaseName doesn't resolve as expected) $dbproperties is $null and the interpolated value silently becomes an empty string, wiping applicationfamily on the recreated database — exactly the regression the preceding comment says this code exists to prevent. Add a guard that throws when $dbproperties or $dbproperties.applicationfamily is null/empty instead of silently writing an empty value.

Suggested fix (apply manually — could not be anchored as a one-click suggestion):

        $dbproperties = Invoke-Sqlcmd -ServerInstance $databaseServerInstance -Query "SELECT [applicationfamily] FROM [$databaseName].[dbo].[`$ndo`$dbproperty]"
        if (-not $dbproperties -or -not $dbproperties.applicationfamily) {
            throw "Could not read applicationfamily from database '$databaseName'; aborting reset to avoid losing this platform-required value."
        }

Line mapping was unavailable, so this was posted as an issue comment.

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why · AL review agent v1.32.4}

[github-actions]

$\textbf{🟡\ Medium\ Severity\ —\ Agent}$

Reset-BcContainerApplicationDatabase runs Clear-BcApplicationDatabase (stop service tier, drop app+tenant+default DBs, flip to single-tenant, recreate 'tenant', restart) followed by license import, System Application publish, user creation, and Restore-BcMultitenancy (switch back to multitenant, mount 'default'), with no try/finally or cleanup path. If any step in this multi-stage, stateful sequence throws (e.g. Import-BcContainerLicense, Publish-BcContainerApp, or a step inside the container script blocks), the container is left half-reset — service tier possibly stopped, Multitenant flipped to False, no tenant mounted — with no automatic recovery, and the caller (NewBcContainer.ps1) has no compensating logic. Consider wrapping the multi-stage sequence in try/catch that at least restarts the service tier and reports which stage failed, so CI failures are diagnosable/retriable rather than leaving the container in an undocumented broken state.

Line mapping was unavailable, so this was posted as an issue comment.

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why · AL review agent v1.32.4}