@yataro set a depth=1 for downloading the powershell's git. We don't need the entire history of it and depth=1 makes things much faster.

@yataro Thanks. I've bumped the package to 7.6.2 and worked my way through the various failing tests. Some turned out to be potentially iffy because openssh is needed for PSRemoting and if it isn't available, some tests fail. I ran into this when trying to build in a clean chroot.

I have built the package on different systems both in and outside a chroot and not been able to reproduce a bunch of the tests that are removed. It's possible that upstream fixed the issue in the meanwhile. Thus, I've commented the ones I was not able to reproduce out to test if anyone can reproduce them on 7.6.2 still.

Sorry for the delay, I've added you as a co-maintainer. Thank you.

@ChrisTX some help from a person who actually uses powershell will help, would you like to co-maintain this? I can see that you are more knowledgeable in powershell and even interested in fixing issues upstream.

The package has a rather long-running issue I should probably have reported before. There's a test in ConvertTo-Json.Tests.ps1 that breaks (even on 7.6.2) on any system that has a local time of UTC+1 to UTC+14. I've reported this issue upstream with details on why this particular test breaks.

This has been an issue for a long while, namely since 2021, as this commit introduced it. I had just assumed upstream knew already about this but given that most people use precompiled binaries for PowerShell, maybe not.

Either way @yataro, could you add that test file to the list of tests being removed? With this change it builds (and checks) for me:

diff --git a/PKGBUILD b/PKGBUILD
index 74ee4c6..9a6bdd3 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -172,6 +172,8 @@ check() {
   rm test/powershell/engine/Remoting/SSHRemotingCmdlets.Tests.ps1
   rm test/powershell/Host/TabCompletion/TabCompletion.Tests.ps1

+  rm test/powershell/Modules/Microsoft.PowerShell.Utility/ConvertTo-Json.Tests.ps1
+
   ## Restore-PSPester()
   unzip -ud temp_pester "$srcdir/pester.4.10.1.nupkg"
   cp -a temp_pester/tools lib/Modules/Pester

Edit: I did attempt a build with all tests intact to see if there's some more tests upstream needs to fix. So far I've diagnosed two of the breaks and made issue here and here . These issues also stem from the way the package is built. I don't think they test Git builds on Linux very often.

Edit 2: The test test/powershell/dsc/dsc.profileresource.Tests.ps1 fails because DSC is not a component included with PowerShell itself but rather found here on GitHub. DSC is however probably not very useful on Arch.

Hello, @dfimium499

I think your request is pretty reasonable. These test workaround have been there before I took over this package, so I just kept it as is (and added some more workarounds when new errors popped out). But, I think, if you want to skip testing, you should use --nocheck

Even if the release is set, there could be some issues associated not with one's setup but Arch Linux in general, so testing released version could be beneficial to find some dependency incompatibilities, etc.

I'll keep check in the package for now, but I'll reconsider your proposal next time when broken test pops up.

Hello,

I'm not very familiar with this package and I'm fairly new to the AUR, so maybe what I'm about to propose is extremely naïve and there's a good reason why it hasn't been done, so please, do explain if I'm terribly wrong.

Now on to my proposal:

Shouldn't we get rid of the check() function altogether? If this were the -git version I'd understand why it might be necessary, but we're installing a set release that should have been tested by both upstream and the maintainer beforehand.

The tests may catch some quirks from a local environment, but considering so many of them are constantly failing left and right either way, I feel like the costs outweigh the benefits. It's gotten to the point where the PKGBUILD blindly deletes tests that mysteriously fail because the maintainer seems to be (reasonably) overwhelmed. Furthermore, the testing process is extremely cumbersome and takes ages to finish (at least on my machine).

In summary:

·Tests fail consistently and are blindly disabled, undermining their purpose.

·Tests slow down the installation significantly.

·This is not a VCS package so their benefits are reduced in comparison.

So in conclusion, I don't think these tests are beneficial and maybe we should do away with them.

Do you think this is a reasonable request or are there any points I'm failing to grasp?

Thank you for your attention!

@airbreather looks like upstream issue, seems reasonable to report