GeezerVison

AppVeyor CI fail is being addressed by #5542 #5554

Mark Kraus (@markekraus) Could you please rebase to pass CI Appveyor?

Ilya (@iSazonov) Rebase wont help this one. It already picked up #5554 in the last empty commit to re-run CI. The problem now is fail in #5567 (which is actually a dup of an older issue where I noted the same behavior randomly happening).

I will rebase anyway in hopes that the WMF links are working now and we don't find some other transient test issue in the feature tests.

The test run got a hard failure:

  WebListener -> /home/travis/build/PowerShell/PowerShell/test/tools/WebListener/bin/Linux/netcoreapp2.0/linux-x64/WebListener.dll
  WebListener -> /home/travis/build/PowerShell/PowerShell/test/tools/WebListener/bin/
Unhandled Exception: System.TypeInitializationException: The type initializer for 'System.Management.Automation.Tracing.PSEtwLog' threw an exception. ---> System.TypeInitializationException: The type initializer for 'System.Management.Automation.Tracing.PSSysLogProvider' threw an exception. ---> System.DllNotFoundException: Unable to load DLL 'psl-native': The specified module or one of its dependencies could not be found.
 (Exception from HRESULT: 0x8007007E)
   at System.Management.Automation.Tracing.NativeMethods.OpenLog(IntPtr ident, SysLogPriority facility)
   at System.Management.Automation.Tracing.SysLogProvider..ctor(String applicationId, PSLevel level, PSKeyword keywords, PSChannel channels)
   at System.Management.Automation.Tracing.PSSysLogProvider..cctor()
   --- End of inner exception stack trace ---
   at System.Management.Automation.Tracing.PSSysLogProvider..ctor()
   at System.Management.Automation.Tracing.PSEtwLog..cctor()
   --- End of inner exception stack trace ---
   at System.Management.Automation.Tracing.PSEtwLog.LogOperationalInformation(PSEventId id, PSOpcode opcode, PSTask task, PSKeyword keyword, Object[] args)
   at Microsoft.PowerShell.UnmanagedPSEntry.Start(String consoleFilePath, String[] args, Int32 argc)
   at Microsoft.PowerShell.ManagedPSEntry.Main(String[] args) in /home/travis/build/PowerShell/PowerShell/src/powershell/Program.cs:line 23

Mark Kraus (@markekraus) I'm not sure how the PSEtwLog came in the play, but it unveils a bug in SysLogProvider.cs, where libpsl-native should be used instead of psl-native. I opened bug #5577 for that.

Is there some reason we don't run the feature tests on every PR? I run into so many CI fails because most of the web cmdlet tests are gated behind the feature tag. Changes made in other PR's that affect the Feature tests are not being properly vetted. In the past even my own PRs have been approved with broken feature tests.

Feature test run takes more time and not every PR needs the full feature test run, so it's not on by default.
It can be turned on with the [Feature] tag, so the maintainer assigned to the PR or any reviewers of the PR can request a feature test run for the PR to be merged.

I'm not sure how the PSEtwLog came in the play

Dan Travison (@dantraMSFT) Have you any ideas why the PSEtwLog is activated from WebListener?

PSEtwLog is not being activated from WebListener...
This line

WebListener -> /home/travis/build/PowerShell/PowerShell/test/tools/WebListener/bin/

indicates that the Publish-PSTestTools has completed:

WebListener is not being run at that point. and the compile appears to be successful

This is failing sometime after Publish-PSTestTools and before the pester tests start. After weblistener is compiled Start-PSPester builds the command line and path then starts a native execution of pwsh. Plenty of places there for PSEtwLog to trigger.

The root cause of the loading failure was that one of our team members uploaded a libpsl-native nuget package that contains a corrupted Linux binary file. The package has been fixed.
As for #5577, .NET Core actually support lack of "lib" prefix in DllImport name (see dotnet/coreclr#1248), but #5580 was merged anyways to make the naming consistent.

thanks. This PR shouldn't have anything outstanding on it.