Summary

Multiple tests fail in the ReleaseAutomationTest comparison of 7.7.0-preview.1 against the 7.6.0-rc.1 baseline. They share a common theme - how MyDocuments / SHARED_MODULES / $PSHOME/Modules paths interact with elevated, service-account, and ZIP/TAR distribution sessions - but split into distinct root causes.

All cases appear as "New Failure" because the ReleaseAutomationTest comparator matches failures by test name/ID against the baseline; tests added, renamed, or running for the first time on a newly-enabled lane in release/v7.7.0-preview.1 are reported as new.

First failing build: ReleaseAutomationTest-27557-ps-671171.

Shared context: PR #27305 "Enable usage in AppContainers"

release/v7.7.0-preview.1 commit 1218a29b8 (merged to master via bec015ffc / PR #27266) changed ModuleIntrinsics.GetPersonalModulePath on Windows from:

Environment.GetFolderPath(Environment.SpecialFolder.MyDocuments)

to:

Environment.GetFolderPath(Environment.SpecialFolder.MyDocuments,
                          Environment.SpecialFolderOption.DoNotVerify)

SpecialFolderOption.None returns "" if the folder does not physically exist; DoNotVerify always returns a non-empty path. It also added SafeDoesPathExist in FileSystemProvider.cs for AppContainer-friendly drive-root validation. PR #26269 made the same DoNotVerify switch in CorePsPlatform.SafeDeriveFromSpecialFolder earlier.

This change is correct for AppContainer scenarios but is only directly relevant to Case 1. Case 3 is independent of #27305 (see Case 3 for details).

Delta between v7.6.0-rc.1 and release/v7.7.0-preview.1 relevant to these cases

1218a29b8 [release/v7.7.0-preview.1] Enable usage in AppContainers (#27305)
7498139ba Update `Microsoft.PowerShell.PSResourceGet` version to 1.2.0 (#27003)
212c5f97e Update to .NET 11 SDK and update dependencies (#26783)
012529a96 Update Microsoft.PowerShell.PSResourceGet version to 1.2.0-rc3 (#26753)
276989fa5 Update Microsoft.PowerShell.PSResourceGet version to 1.2.0-rc1 (#26691)
592668bd0 Refactor the module path construction code to make it more robust and easier to maintain (#26565)
2a49561af Update `Microsoft.PowerShell.PSResourceGet` to `v1.2.0-preview5` (#26589)
c7ee0d294 Fix checks for local user config file paths (#26269)

Case 1 - ModuleIntrinsics.GetPSModulePath "User" on elevated lanes

Lanes affected

• Linux: mariner_ARM64, Ubuntu22, debian12, linux_Arm32, ubi9
• macOS: macOS, macOS Tar
• Windows: win_arm64, Windows Server 2016

Sample failure

Expected '/root/.local/share/powershell/Modules' to be found in collection
@('/home/cloudtest/PSPackage/download/PowerShell/Modules',
  '/home/cloudtest/PSPackage/download/Test/test/tools/Modules',
  '/home/cloudtest/.local/share/powershell/Modules'),
but it was not found.
at <ScriptBlock>, test/powershell/engine/Module/ModulePath.Tests.ps1: line 247
247:         $currentModulePathElements | Should -Contain $mPath

Root cause

The test assumes [ModuleIntrinsics]::GetPSModulePath("User") must already be present in the inherited $env:PSModulePath, which does not hold for the elevated test leg:

1. The elevated leg is launched via sudo -E pwsh ... from build.psm1#L2020.
2. sudo -E preserves $env:PSModulePath from the launching user (cloudtest) but most sudoers configurations reset HOME to /root.
3. GetPSModulePath("User") is computed live from the new HOME via Platform.SelectProductNameForDirectory(USER_MODULES), producing /root/.local/share/powershell/Modules.
4. The inherited $env:PSModulePath still contains /home/cloudtest/.local/share/powershell/Modules, so $currentModulePathElements | Should -Contain $mPath fails.

The same shape applies on elevated Windows lanes - the elevated process is launched from a wrapper that already established PSModulePath, and elevation/service-account contexts can produce a different MyDocuments folder than the one baked into the inherited PSModulePath. PR #27305 surfaces the Windows variant because DoNotVerify now returns a value that previously would have been "".

Fix

This is a test bug. Two reasonable options:

Option A - Skip when elevation crossed a user boundary (smallest change):

# test/powershell/engine/Module/ModulePath.Tests.ps1, inside the "User" case
if ($Name -eq ''User'') {
    $userPath = [System.Management.Automation.ModuleIntrinsics]::GetPSModulePath(''User'')
    if ($currentModulePathElements -notcontains $userPath) {
        Set-ItResult -Skipped -Because ''Elevation session has a different HOME/MyDocuments than the launching user; the inherited PSModulePath does not reflect current user-scope.''
        return
    }
}

Option B - Reconcile $env:PSModulePath after elevation (in the test harness):

Add to the elevated test entry point (e.g. around build.psm1#L2020):

$env:PSModulePath = [System.Management.Automation.ModuleIntrinsics]::GetModulePath(
    $env:PSModulePath, $null, $null)

Option A is lower-risk. Option B also makes Install-Module -Scope CurrentUser inside elevated legs behave more intuitively.

Case 3 - PSResourceGet / PowerShellGet AllUsers install on all elevated lanes

Tests

Note: ReleaseAutomationTest test IDs are run-relative and not stable between runs. The same It blocks were tracked as 100120 / 100144 in an earlier draft; only test names are stable.

Lanes affected (all elevated)

• win_arm64
• WindowsServer2016ZIP
• ubuntu22_TAR, ubuntu22
• ubi9
• arm64
• macOS TAR, macOS
• linux_arm32
• debian12
• azurelinux30

The coverage spans both portable (ZIP/TAR) and package-installed lanes, ruling out portable-distribution-only theories.

Confirmed regression

Both tests passed on the v7.6.0-rc.1 baseline (confirmed via the rc.1 ReleaseAutomationTest xUnit output: both result="Success" success="True" executed="True" for PSResourceGet - Module tests (Admin) and PowerShellGet - Module tests (Admin)). They now fail on preview.1, so this is a real product-side regression, not a comparator artifact.

Key assertion

Install-[Module|PSResource] -Name $TestModule -Scope AllUsers -ErrorAction Stop
$module = Get-Module $TestModule -ListAvailable
$module.ModuleBase.StartsWith($script:programFilesModulesPath) | Should -BeTrue

$programFilesModulesPath is built from [Platform]::SelectProductNameForDirectory("SHARED_MODULES"), which on Linux is hardcoded:

// src/System.Management.Automation/CoreCLR/CorePsPlatform.cs
case XDG_Type.SHARED_MODULES:
    return "/usr/local/share/powershell/Modules";

That value does not depend on HOME / sudo -E, so this case is NOT caused by #27305. The test files themselves are unchanged between v7.6.0-rc.1 and release/v7.7.0-preview.1 (git log v7.6.0-rc.1..release/v7.7.0-preview.1 -- <path> returns no commits), so it is not a rename/new-test artifact either.

Real candidates (delta commits between v7.6.0-rc.1 and release/v7.7.0-preview.1)

PowerShellGet 2.2.5 was not version-bumped between the two releases. Because 101755 also regressed and PowerShellGet itself did not change, the PSResourceGet 1.2.0 GA bump cannot be the sole explanation - a shared product-side change is required. The strongest single-suspect candidate that would explain regressions in both Install-PSResource -Scope AllUsers (test 100798) and Install-Module -Scope AllUsers (test 101755) is PR #26565 (592668bd0), via the same AddToPath -> UpdatePath rewrite already confirmed responsible for the test 108309 regression tracked in #27346.

Likely mechanism

The failing assertion is:

$module = Get-Module $TestModule -ListAvailable
$module.ModuleBase.StartsWith($script:programFilesModulesPath, [StringComparison]::OrdinalIgnoreCase) | Should -BeTrue

$script:programFilesModulesPath is byte-identical between rc.1 and preview.1 (/usr/local/share/powershell/Modules on Linux, $env:ProgramFiles/PowerShell/Modules on Windows). The install cmdlet is documented to land AllUsers-scoped modules under that root, so the only way the assertion fails is if Get-Module -ListAvailable returns a $module whose ModuleBase is not under $programFilesModulesPath - i.e. another copy of the module is being resolved first from a different PSModulePath entry.

Get-Module -ListAvailable enumerates PSModulePath in order. PR #26565 changed:

• AddToPath -> UpdatePath (HashSet<string> dedup using Path.TrimEndingDirectorySeparator)
• insertPosition now advances after each insert (forward order), where rc.1's AddToPath did not advance it (reverse order)
• Static static ModuleIntrinsics() { SetModulePath(); } initializer added

Any of these can change the relative ordering of (a) the AllUsers install root and (b) other paths on PSModulePath that may also contain a copy of $TestModule (e.g. test-tools modules folder, downloaded test scaffolding). If a non-programFilesModulesPath location now sorts earlier on preview.1, Get-Module -ListAvailable | Select-Object -First 1 returns it, and StartsWith($programFilesModulesPath) fails.

This is consistent with the regression being across all elevated lanes (the change is in path construction, not platform-specific) and with PowerShellGet 2.2.5 being unchanged (the bug isn't in the install cmdlet, it's in which copy Get-Module -ListAvailable resolves first).

Fix plan

1. Verify the mechanism. On a preview.1 build, on any failing lane, after Install-PSResource -Name $TestModule -Scope AllUsers run Get-Module $TestModule -ListAvailable | Select-Object Name, ModuleBase and inspect (a) which paths are returned and (b) the current $env:PSModulePath ordering. Compare against rc.1.
2. If mechanism confirmed: the fix lives in ModuleIntrinsics.GetModulePath / UpdatePath and is the same family of change as the Test failures from module-path refactor PR #26565: tests 103778 / 103842 / 108309 fail on ZIP/TAR/portable distribution lanes #27346 fix - either always include psHomeModulePath alongside HKLM (as proposed in Test failures from module-path refactor PR #26565: tests 103778 / 103842 / 108309 fail on ZIP/TAR/portable distribution lanes #27346) or restore rc.1's reverse-insertion ordering for the affected branch.
3. If mechanism not confirmed: widen the bisect across the delta commits above (top suspects remain Refactor the module path construction code to make it more robust and easier to maintain #26565, then PSResourceGet 1.2.0 GA Update Microsoft.PowerShell.PSResourceGet version to 1.2.0 #27003 for 100798 only, then .NET 11 SDK Update to .NET 11 SDK and update dependencies #26783).

Branch strategy

Both remaining cases exist on master as well as release/v7.7.0-preview.1:

• Case 1 - User variant: test file and sudo -E wrapper are identical on both. Fix master first, backport test change to preview.1.
• Case 1 - Machine variant (test 100145): same ModuleIntrinsics regression as Test failures from module-path refactor PR #26565: tests 103778 / 103842 / 108309 fail on ZIP/TAR/portable distribution lanes #27346 / Case 3. Fix master first, backport.
• Case 3: confirmed regression. Top suspect is ModuleIntrinsics (PR Refactor the module path construction code to make it more robust and easier to maintain #26565). Fix master first, backport to preview.1. Coordinate with the Test failures from module-path refactor PR #26565: tests 103778 / 103842 / 108309 fail on ZIP/TAR/portable distribution lanes #27346 product-side fix since both target the same code path. If bisect re-points at PSResourceGet 1.2.0 GA, the product delta lives in the NuGet package; either ship a patched 1.2.x bump or revert the PSResourceGet bump on the release branch.

Per .github/instructions/code-review-branch-strategy.instructions.md, release branches should not carry workarounds for issues that also exist on master.

Files affected

• test/powershell/engine/Module/ModulePath.Tests.ps1 (lines 206-250) - Case 1 (User variant test fix)
• build.psm1 (line 2020) - Case 1 User variant (option B only)
• src/System.Management.Automation/engine/Modules/ModuleIntrinsics.cs - Case 1 Machine variant (test 100145) and Case 3 (top suspect; same code path as Test failures from module-path refactor PR #26565: tests 103778 / 103842 / 108309 fail on ZIP/TAR/portable distribution lanes #27346)
• test/powershell/Modules/Microsoft.PowerShell.PSResourceGet/Microsoft.PowerShell.PSResourceGet.Tests.ps1 (line 241) - Case 3 (test 100798; file unchanged between rc.1 and preview.1)
• test/powershell/Modules/PowerShellGet/PowerShellGet.Tests.ps1 (line 172) - Case 3 (test 101755; file unchanged between rc.1 and preview.1)
• src/Modules/PSGalleryModules.csproj - Case 3 (only if bisect re-points at Update Microsoft.PowerShell.PSResourceGet version to 1.2.0 #27003)

Related

• Baseline for the comparison: v7.6.0-rc.1 (tag 9a42b9152, Feb 19 2026)
• Target: release/v7.7.0-preview.1
• Regression surfaced by [release/v7.7.0-preview.1] Enable usage in AppContainers #27305 / Enable usage in AppContainers #27266 (Enable usage in AppContainers) - Case 1 (Windows portion)
• Case 2 was extracted to issue Test failures from module-path refactor PR #26565: tests 103778 / 103842 / 108309 fail on ZIP/TAR/portable distribution lanes #27346
• PSResourceGet 1.2.0 GA bump Update Microsoft.PowerShell.PSResourceGet version to 1.2.0 #27003 / [release/v7.6] Update Microsoft.PowerShell.PSResourceGet version to 1.2.0 #27007 - Case 3 candidate
• .NET 10 -> .NET 11 SDK update Update to .NET 11 SDK and update dependencies #26783 - Case 3 candidate
• First failing build: ReleaseAutomationTest-27557-ps-671171