René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"ReleaseAutomationTest new failures in 7.7.0-preview.1: module-path / MyDocuments test assumptions (3 distinct cases)","articleBody":"## Summary\n\nMultiple 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.\n\n| # | Case | Lanes | Root cause | Tracking |\n|---|---|---|---|---|\n| 1 | `ModuleIntrinsics.GetPSModulePath` API tests | All elevated Linux/macOS lanes (User variant); all elevated Windows + Linux/macOS lanes (Machine variant, test 100145) | User variant: `sudo -E` drops `HOME`; Machine variant: cross-platform PSModulePath construction regression - top suspect PR #26565 | This issue (below) |\n| 2 | Module-path construction tests fail on portable (ZIP/TAR) and additional lanes | `WindowsServer2016ZIP - Unelevated`, `ubuntu22 TAR`, `mariner ARM64`, `macOS TAR`, `macOS`, `linux ARM32`, `debian12`, `azurelinux30` | Downstream of PR #26565 (\"Refactor the module path construction code\"), which is not in `v7.6.0-rc.1` | **Tracked in #27346** |\n| 3 | PSResourceGet / PowerShellGet `AllUsers` install | All elevated lanes (Windows / Linux / macOS, portable + package-installed) | Confirmed regression vs rc.1; top suspect is PR #26565 (`AddToPath` -\u003e `UpdatePath` rewrite) - same code path as #27346. Unrelated to #27305 | This issue (below) |\n\nAll 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.\n\nFirst failing build: `ReleaseAutomationTest-27557-ps-671171`.\n\n---\n\n## Shared context: PR #27305 \"Enable usage in AppContainers\"\n\n`release/v7.7.0-preview.1` commit `1218a29b8` (merged to `master` via `bec015ffc` / PR #27266) changed `ModuleIntrinsics.GetPersonalModulePath` on Windows from:\n\n```csharp\nEnvironment.GetFolderPath(Environment.SpecialFolder.MyDocuments)\n```\n\nto:\n\n```csharp\nEnvironment.GetFolderPath(Environment.SpecialFolder.MyDocuments,\n                          Environment.SpecialFolderOption.DoNotVerify)\n```\n\n`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.\n\nThis 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).\n\n### Delta between v7.6.0-rc.1 and release/v7.7.0-preview.1 relevant to these cases\n\n```\n1218a29b8 [release/v7.7.0-preview.1] Enable usage in AppContainers (#27305)\n7498139ba Update `Microsoft.PowerShell.PSResourceGet` version to 1.2.0 (#27003)\n212c5f97e Update to .NET 11 SDK and update dependencies (#26783)\n012529a96 Update Microsoft.PowerShell.PSResourceGet version to 1.2.0-rc3 (#26753)\n276989fa5 Update Microsoft.PowerShell.PSResourceGet version to 1.2.0-rc1 (#26691)\n592668bd0 Refactor the module path construction code to make it more robust and easier to maintain (#26565)\n2a49561af Update `Microsoft.PowerShell.PSResourceGet` to `v1.2.0-preview5` (#26589)\nc7ee0d294 Fix checks for local user config file paths (#26269)\n```\n\n---\n\n## Case 1 - `ModuleIntrinsics.GetPSModulePath \"User\"` on elevated lanes\n\n### Lanes affected\n\n- Linux: `mariner_ARM64`, `Ubuntu22`, `debian12`, `linux_Arm32`, `ubi9`\n- macOS: `macOS`, `macOS Tar`\n- Windows: `win_arm64`, `Windows Server 2016`\n\n### Sample failure\n\n```\nExpected '/root/.local/share/powershell/Modules' to be found in collection\n@('/home/cloudtest/PSPackage/download/PowerShell/Modules',\n  '/home/cloudtest/PSPackage/download/Test/test/tools/Modules',\n  '/home/cloudtest/.local/share/powershell/Modules'),\nbut it was not found.\nat \u003cScriptBlock\u003e, test/powershell/engine/Module/ModulePath.Tests.ps1: line 247\n247:         $currentModulePathElements | Should -Contain $mPath\n```\n\n### Root cause\n\nThe test assumes `[ModuleIntrinsics]::GetPSModulePath(\"User\")` must already be present in the inherited `$env:PSModulePath`, which does not hold for the elevated test leg:\n\n1. The elevated leg is launched via `sudo -E pwsh ...` from `build.psm1#L2020`.\n2. `sudo -E` preserves `$env:PSModulePath` from the launching user (`cloudtest`) but most sudoers configurations reset `HOME` to `/root`.\n3. `GetPSModulePath(\"User\")` is computed live from the new `HOME` via `Platform.SelectProductNameForDirectory(USER_MODULES)`, producing `/root/.local/share/powershell/Modules`.\n4. The inherited `$env:PSModulePath` still contains `/home/cloudtest/.local/share/powershell/Modules`, so `$currentModulePathElements | Should -Contain $mPath` fails.\n\nThe 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 `\"\"`.\n\n### Fix\n\n**This is a test bug.** Two reasonable options:\n\n**Option A - Skip when elevation crossed a user boundary (smallest change):**\n\n```powershell\n# test/powershell/engine/Module/ModulePath.Tests.ps1, inside the \"User\" case\nif ($Name -eq ''User'') {\n    $userPath = [System.Management.Automation.ModuleIntrinsics]::GetPSModulePath(''User'')\n    if ($currentModulePathElements -notcontains $userPath) {\n        Set-ItResult -Skipped -Because ''Elevation session has a different HOME/MyDocuments than the launching user; the inherited PSModulePath does not reflect current user-scope.''\n        return\n    }\n}\n```\n\n**Option B - Reconcile `$env:PSModulePath` after elevation (in the test harness):**\n\nAdd to the elevated test entry point (e.g. around `build.psm1#L2020`):\n\n```powershell\n$env:PSModulePath = [System.Management.Automation.ModuleIntrinsics]::GetModulePath(\n    $env:PSModulePath, $null, $null)\n```\n\nOption A is lower-risk. Option B also makes `Install-Module -Scope CurrentUser` inside elevated legs behave more intuitively.\n\n---\n\n## Case 3 - PSResourceGet / PowerShellGet AllUsers install on all elevated lanes\n\n### Tests\n\n| ID (preview.1 run) | Describe/It | File |\n|---|---|---|\n| 100798 | `PSResourceGet - Module tests (Admin) - Should install a module correctly to the required location with AllUsers scope` | `test/powershell/Modules/Microsoft.PowerShell.PSResourceGet/Microsoft.PowerShell.PSResourceGet.Tests.ps1#L241-L249` |\n| 101755 | `PowerShellGet - Module tests (Admin) - Should install a module correctly to the required location with AllUsers scope` | `test/powershell/Modules/PowerShellGet/PowerShellGet.Tests.ps1#L172-L178` |\n\nNote: `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.\n\n### Lanes affected (all elevated)\n\n- `win_arm64`\n- `WindowsServer2016ZIP`\n- `ubuntu22_TAR`, `ubuntu22`\n- `ubi9`\n- `arm64`\n- `macOS TAR`, `macOS`\n- `linux_arm32`\n- `debian12`\n- `azurelinux30`\n\nThe coverage spans both portable (ZIP/TAR) and package-installed lanes, ruling out portable-distribution-only theories.\n\n### Confirmed regression\n\nBoth 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.\n\n### Key assertion\n\n```powershell\nInstall-[Module|PSResource] -Name $TestModule -Scope AllUsers -ErrorAction Stop\n$module = Get-Module $TestModule -ListAvailable\n$module.ModuleBase.StartsWith($script:programFilesModulesPath) | Should -BeTrue\n```\n\n`$programFilesModulesPath` is built from `[Platform]::SelectProductNameForDirectory(\"SHARED_MODULES\")`, which on Linux is **hardcoded**:\n\n```csharp\n// src/System.Management.Automation/CoreCLR/CorePsPlatform.cs\ncase XDG_Type.SHARED_MODULES:\n    return \"/usr/local/share/powershell/Modules\";\n```\n\nThat 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 -- \u003cpath\u003e` returns no commits), so it is not a rename/new-test artifact either.\n\n### Real candidates (delta commits between v7.6.0-rc.1 and release/v7.7.0-preview.1)\n\n| Commit | Why it matters | Case relevance |\n|---|---|---|\n| `7498139ba` - PR #27003 bump `Microsoft.PowerShell.PSResourceGet` to `1.2.0` (final GA) | New GA could change `Install-PSResource -Scope AllUsers` install path logic | Top suspect for 100120 |\n| `012529a96` - PR #26753 `PSResourceGet 1.2.0-rc3` | Same codebase, interim step | Secondary for 100120 |\n| `592668bd0` - PR #26565 \"Refactor module path construction\" | Rewrote `UpdatePath`, static-initialized `SetModulePath`, changed dedup to use `Path.TrimEndingDirectorySeparator` + `HashSet\u003cstring\u003e` | Top suspect for 100144 |\n| `212c5f97e` - PR #26783 .NET 10 -\u003e .NET 11 SDK | Runtime `GetFolderPath` / path semantics can shift subtly across SDK majors | Possible, lower likelihood |\n| `1218a29b8` / `bec015ffc` - PR #27305 AppContainers | Windows-only behavior change | Unrelated |\n\nPowerShellGet `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` -\u003e `UpdatePath` rewrite already confirmed responsible for the test 108309 regression tracked in #27346.\n\n### Likely mechanism\n\nThe failing assertion is:\n\n```powershell\n$module = Get-Module $TestModule -ListAvailable\n$module.ModuleBase.StartsWith($script:programFilesModulesPath, [StringComparison]::OrdinalIgnoreCase) | Should -BeTrue\n```\n\n`$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.\n\n`Get-Module -ListAvailable` enumerates `PSModulePath` in order. PR #26565 changed:\n\n- `AddToPath` -\u003e `UpdatePath` (`HashSet\u003cstring\u003e` dedup using `Path.TrimEndingDirectorySeparator`)\n- `insertPosition` now advances after each insert (forward order), where rc.1's `AddToPath` did not advance it (reverse order)\n- Static `static ModuleIntrinsics() { SetModulePath(); }` initializer added\n\nAny 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.\n\nThis 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).\n\n### Fix plan\n\n1. **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.\n2. **If mechanism confirmed:** the fix lives in `ModuleIntrinsics.GetModulePath` / `UpdatePath` and is the same family of change as the #27346 fix - either always include `psHomeModulePath` alongside HKLM (as proposed in #27346) or restore rc.1's reverse-insertion ordering for the affected branch.\n3. **If mechanism not confirmed:** widen the bisect across the delta commits above (top suspects remain #26565, then PSResourceGet 1.2.0 GA #27003 for 100798 only, then .NET 11 SDK #26783).\n\n---\n\n## Branch strategy\n\nBoth remaining cases exist on `master` as well as `release/v7.7.0-preview.1`:\n\n- Case 1 - User variant: test file and `sudo -E` wrapper are identical on both. **Fix master first**, backport test change to preview.1.\n- Case 1 - Machine variant (test 100145): same `ModuleIntrinsics` regression as #27346 / Case 3. **Fix master first**, backport.\n- Case 3: confirmed regression. Top suspect is `ModuleIntrinsics` (PR #26565). **Fix master first**, backport to preview.1. Coordinate with the #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.\n\nPer `.github/instructions/code-review-branch-strategy.instructions.md`, release branches should not carry workarounds for issues that also exist on master.\n\n---\n\n## Files affected\n\n- `test/powershell/engine/Module/ModulePath.Tests.ps1` (lines 206-250) - Case 1 (User variant test fix)\n- `build.psm1` (line 2020) - Case 1 User variant (option B only)\n- `src/System.Management.Automation/engine/Modules/ModuleIntrinsics.cs` - Case 1 Machine variant (test 100145) and Case 3 (top suspect; same code path as #27346)\n- `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)\n- `test/powershell/Modules/PowerShellGet/PowerShellGet.Tests.ps1` (line 172) - Case 3 (test 101755; file unchanged between rc.1 and preview.1)\n- `src/Modules/PSGalleryModules.csproj` - Case 3 (only if bisect re-points at #27003)\n\n## Related\n\n- Baseline for the comparison: **v7.6.0-rc.1** (tag `9a42b9152`, Feb 19 2026)\n- Target: **release/v7.7.0-preview.1**\n- Regression surfaced by #27305 / #27266 (Enable usage in AppContainers) - Case 1 (Windows portion)\n- Case 2 was extracted to issue #27346\n- PSResourceGet 1.2.0 GA bump #27003 / #27007 - Case 3 candidate\n- .NET 10 -\u003e .NET 11 SDK update #26783 - Case 3 candidate\n- First failing build: `ReleaseAutomationTest-27557-ps-671171`","author":{"url":"https://github.com/jshigetomi","@type":"Person","name":"jshigetomi"},"datePublished":"2026-04-23T16:18:16.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":0},"url":"https://github.com/27343/PowerShell/issues/27343"}