Test failure on Alpine Linux with PSTests.Parallel.FileSystemProviderTests.TestMode

[ayakael]

Prerequisites

• Write a descriptive title.
• Make sure you are able to repro it on the latest released version
• Search the existing issues.
• Refer to the FAQ.
• Refer to Differences between Windows PowerShell 5.1 and PowerShell.

Steps to reproduce

Currently building a package for powershell on Alpine Linux, now that dotnet6 is implemented. All tests but PSTests.Parallel.FileSystemProviderTests.TestMode pass.

To reproduce, git clone https://gitlab.alpinelinux.org/ayakael/aports -b testing/powershell-test-fail and abuild -r in any Alpine environment equal or greater to version 3.16.

Expected behavior

All checks should pass.

Actual behavior

All but one passes.

Error details

Error is as follows:

[xUnit.net 00:00:02.08]     PSTests.Parallel.FileSystemProviderTests.TestMode [FAIL]
  Failed PSTests.Parallel.FileSystemProviderTests.TestMode [3 ms]
  Error Message:
   Assert.Equal() Failure
          ↓ (pos 0)
Expected: -----
Actual:   l----
          ↑ (pos 0)
  Stack Trace:
     at PSTests.Parallel.FileSystemProviderTests.TestMode() in /var/build/powershell/testing/powershell/src/PowerShell-7.2.6/test/xUnit/csharp/test_FileSystemProvider.cs:line 123

### Environment data

```powershell
Name                           Value
----                           -----
PSVersion                      7.2.6
PSEdition                      Core
GitCommitId                    7.2.6
OS                             Linux 5.4.157-1-pve #1 SMP PVE 5.4.157-1 (Mon, 29 Nov 2021 12:01:44 +0100)
Platform                       Unix
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

Visuals

No response

[iSazonov]

I wonder why you build pwsh for Alpine if MSFT releases official PowerShell package for the OS.

[ayakael]

Alpine Linux, much like other distributions, do not accept inclusion of binary packages in their main repository. Thus, every package need to be built from source. This has lead to much bigger projects like dotnet's source-build, allowing dotnet to be built from source for inclusion in official distro repositories.

Indeed, as it is self-hosted, ideally I should use pwsh to build pwsh, but alas that is not ideal from a package maintainer's perspective: self-hosted applications are difficult to bootstrap.

[iSazonov]

Indeed, as it is self-hosted, ideally I should use pwsh to build pwsh, but alas that is not ideal from a package maintainer's perspective: self-hosted applications are difficult to bootstrap.

I have tried repeatedly to fix this, but all PRs have been rejected by MSFT PowerShell team. :-( Perhaps you can change their minds.

If I am not mistaken, the scripts in this repository run on Windows and use cross-compilation to prepare packages for ARM. So you will have to redo them to get your process going.

[ayakael]

Indeed, as it is self-hosted, ideally I should use pwsh to build pwsh, but alas that is not ideal from a package maintainer's perspective: self-hosted applications are difficult to bootstrap.

I have tried repeatedly to fix this, but all PRs have been rejected by MSFT PowerShell team. :-( Perhaps you can change their minds.

If I am not mistaken, the scripts in this repository run on Windows and use cross-compilation to prepare packages for ARM. So you will have to redo them to get your process going.

Could you point me to relevant PRs so I can study their reasoning?

[iSazonov]

@ayakael There is not one PR that solves the whole problem. I tried to start one, two... but it was not accepted.

Right now the build is done by Start-PSBuild from Build.psm1
This consists of several phases that are implemented by this script:

1. dotnet restore
2. build TypeCatalog
3. build resources
4. dotnet compile
5. restore psmodules
6. I may have missed something. In addition, there are non-trivial scripts that do packaging.

My intention was to move most of these steps into csproj so as not to depend on pwsh and build ps script(s).
Their argument was that it's easier for us to write a build script than to support csproj. Although I think there is an acceptable compromise.

[ayakael]

I see. I implemented what appears to be a successful building script here. It is based on an archlinux AUR. In fact, you can already test the package on Alpine Linux by activating the edge/testing repo and executing sudo apk add powershell. It seems to work, but there are still a few issues needing fixing before inclusion in the release repos.

As I don't use powershell, I do not know how to fully test its general functionnality. This project was started in response to a user's package request. I suppose one thing I could do is use the aport as-is to bootstrap a Build.psm1 based build.

[ayakael]

I built pwsh using itself, and then re-did the tests, and the error occurs again. I thus can confirm that this is an issue not with my building process, but with powershell, proper.

[iSazonov]

I built pwsh using itself, and then re-did the tests, and the error occurs again. I thus can confirm that this is an issue not with my building process, but with powershell, proper.

The error says that /bis/echo is a link on your system - is it true?

As for build process, you could directly communicate with @SteveL-MSFT.
I still believe we could move some steps (TypeGen, ResGen at least) to csproj and simplify life for Linux maintainers like you.

[ayakael]

I built pwsh using itself, and then re-did the tests, and the error occurs again. I thus can confirm that this is an issue not with my building process, but with powershell, proper.

The error says that /bis/echo is a link on your system - is it true?

As for build process, you could directly communicate with @SteveL-MSFT. I still believe we could move some steps (TypeGen, ResGen at least) to csproj and simplify life for Linux maintainers like you.

Oh, so that's how that error should be interpreted. Indeed, /bin/echo is a symbolic link to, by default, /bin/busybox.

[ayakael]

Then, to fix the test I just need to point to an actual executable file. It was under my nose this whole time.

[ayakael]

The following patch fixed the test on Alpine:

From 04b0c8b1274918015c91f609cd63fdda6099ab95 Mon Sep 17 00:00:00 2001
Patch-Source: https://github.com/PowerShell/PowerShell/issues/17889
From: Antoine Martin <dev@ayakael.net>
Date: Tue, 26 Jul 2022 20:34:30 -0400
Subject: [PATCH 1/1] Neutralize PSTests.Parallel.FileSystemProviderTests.TestMode

PSTests.Parallel.FileSystemProviderTests.TestMode prints error:
[xUnit.net 00:00:06.26]     PSTests.Parallel.FileSystemProviderTests.TestMode [FAIL]
  Failed PSTests.Parallel.FileSystemProviderTests.TestMode [5 ms]
  Error Message:
   Assert.Equal() Failure
          ↓ (pos 0)
Expected: -----
Actual:   l----
          ↑ (pos 0)
  Stack Trace:
     at PSTests.Parallel.FileSystemProviderTests.TestMode() in /home/user/projects/powershell/testing/powershell/src/PowerShell-7.2.5/test/xUnit/csharp/test_FileSystemProvider.cs:line 123

This patch fixes this failed test by pointing the to-be-tested file to
/bin/busybox rather than /bin/echo, as the latter is a symbolic link

---
 test/xUnit/csharp/test_FileSystemProvider.cs | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/test/xUnit/csharp/test_FileSystemProvider.cs b/test/xUnit/csharp/test_FileSystemProvider.cs
index 85ab0b2ee..160862146 100644
--- a/test/xUnit/csharp/test_FileSystemProvider.cs
+++ b/test/xUnit/csharp/test_FileSystemProvider.cs
@@ -109,7 +109,7 @@ namespace PSTests.Parallel
             {
                 directoryObject = new DirectoryInfo(@"/");
                 fileObject = new FileInfo(@"/etc/hosts");
-                executableObject = new FileInfo(@"/bin/echo");
+                executableObject = new FileInfo(@"/bin/busybox");
             }
             else
             {
-- 
2.36.2

As it is fixed, closing issue. Thanks for your help! As for moving build to csproj, it would've indeed made things easier. I hope ya'll move this direction! As for me, the package building script reverse engineered from build.psm1 works. I'll try to eventually send some PRs ya'll's way.