Skip to content

Conversation

@markekraus
Copy link
Contributor

ref #5464 , #2504, #3267

This should alleviate some of the macOS HttpListener related failures.

@markekraus
Copy link
Contributor Author

markekraus commented Nov 25, 2017

AppVeyor CI fail is being addressed by #5542 #5554

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it ok to use explicit port?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In this case, the port is not used. The header is echoed back like so:

Link: <http://localhost:8080/PowerShell?test=linkheader&maxlinks=5&linknumber=1>; rel="self"
Link: <http://localhost:8080/PowerShell?test=linkheader&maxlinks=5&linknumber=2>; rel="next"
Link: <http://localhost:8080/PowerShell?test=linkheader&maxlinks=5&linknumber=5>; rel="last"

and then the test is to ensure the RelationLink.Count is 3 and the the exact urls are provided. These URLs could be anything for this test, but since the linkheader API still lives on HttpListener and not WebListener, I kept the URLs as is so they can actually be useful if you manually repro the test.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you please explain why we want to remove these tests?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did in the PR description.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can remove the BeforeAll .

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please remove the extra line.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We never use the formatting.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do i really need to have this all on one line where you have to scroll for an eternity to see it?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe we use the pattern:

if (Request.Query.TryGetValue("statuscode", out statusCodes) &&   
    Int32.TryParse(statusCodes.FirstOrDefault(), out statusCode))  
{
    ...
}

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fixed

@iSazonov
Copy link
Collaborator

@markekraus Could you please rebase to pass CI Appveyor?

@markekraus
Copy link
Contributor Author

@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.

@markekraus markekraus force-pushed the HttpListenerToWebListener branch from f256997 to 26d4ebe Compare November 29, 2017 10:11
@daxian-dbw
Copy link
Member

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

@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.

@markekraus
Copy link
Contributor Author

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.

@daxian-dbw
Copy link
Member

daxian-dbw commented Nov 29, 2017

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.

@iSazonov
Copy link
Collaborator

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

@dantraMSFT Have you any ideas why the PSEtwLog is activated from WebListener?

@markekraus
Copy link
Contributor Author

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:

Publish-PSTestTools | ForEach-Object {Write-Host $_}

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.

@daxian-dbw
Copy link
Member

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.

@markekraus
Copy link
Contributor Author

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

@adityapatwardhan adityapatwardhan merged commit 95a8a64 into PowerShell:master Dec 4, 2017
@TravisEz13 TravisEz13 added this to the 6.0.0-RC.2 milestone Dec 5, 2017
TravisEz13 pushed a commit to TravisEz13/PowerShell that referenced this pull request Dec 5, 2017
* Add Response Controller

* [Feature] Replace HttpListener Response tests with WebListener
TravisEz13 pushed a commit that referenced this pull request Dec 5, 2017
* Add Response Controller

* [Feature] Replace HttpListener Response tests with WebListener
@markekraus markekraus deleted the HttpListenerToWebListener branch January 19, 2018 18:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants