Open LogicuL opened 5 years ago
Having the exact same problem. I'm using Powershell Start-Process to start winappdriver in background. When running the startup scipt manually winappdriver starts nicely - but when I run it through Jenkins, winappdriver exits immediately.
Not sure, but it might be related to how winappdriver handles stdin. The manual run has an interactive session of course, but the Jenkins initiated run probably does not.
By setting RedirectStandardInput option for Start-Process and pointing it to empty file, the problem happens also for manual runs. Wish I knew what does winappdriver expect from stdin...?
I now switched from Power-Shell:Start-Process to plain old START, and the problem went a way. Looking back, I switched to Start-Process so I could easily 1) prevent the extra console window and 2) to redirect stderr and stdout to logs.
Workaround that works for me, in a powershell-script (.ps1):
<clip>
Start-Process 'cmd' -ArgumentList '/c "C:\ProgramFiles (x86)\Windows Application Driver\WinAppDriver.exe" 1>winappdriver_out.log 2>winappdriver_err.log` -WindowStyle Hidden
<clip>
What I assume happens with that piece of script: the hidden cmd window satisfies the odd stdin-behaviour of winappdriver.
To get the logs in file ( which is a very basic requirement in CI ), the redirection of stdout and stderr had to be done in the cmd-script part instead of using the RedirectStandardOutput and RedirectStandardError flags of Start-Process: if I used the flags, it probably also affected RedirectStandardInput...and again did not work.
Hi @karniemi . Sorry for the late reply. Thank you for your answer. The same kind of workaround worked for us in the end.
We are seeing this also, but we would really like to keep the WinAppDriver output in the same console output as VSTest output so we can see exactly what tests cause what WinAppDriver failures.
The solution propsed above by @karniemi is nice but then the WinAppDriver output is kept separate and it isn't clear what tests cause what WinAppDriver output.
For more context our build system is Teamcity running WinAppDriver and VSTest based UITests.
Here's what we tried in powershell
start-process -NoNewWindow -FilePath "C:\Program Files (x86)\Windows Application driver\winappdriver.exe" -ArgumentList "1234"
start-process -NoNewWindow -FilePath "C:\Program Files (x86)\Microsoft Visual Studio\2017\TestAgent\Common7\IDE\CommonExtensions\Microsoft\TestWindow\vstest.console.exe" -ArgumentList "UITests\UITests.dll /Logger:trx /Platform:x86" -Wait
And with batch script
start /b cmd /c "C:\Program Files (x86)\Windows Application driver\winappdriver.exe" 1234
start /wait /b cmd /c "C:\Program Files (x86)\Microsoft Visual Studio\2017\TestAgent\Common7\IDE\CommonExtensions\Microsoft\TestWindow\vstest.console.exe" UITests\UITests.dll /Logger:trx /Platform:x86
Both work locally, but under teamcity because it is noninteractive there isn't a stdin, it doesn't work.
@LogicuL: could you reopen this ticket? Users will hit this odd issue, and our workarounds are not the correct solution...
The workarounds described above are not working for everyone. Reopening the issue.
I'm also having this issue using TeamCity. What I've done as a workaround is to create a Windows scheduled task and keep it always up and running. I wonder if there is any progress on this fix, though.
I created a repository that can reproduce the issue here: https://github.com/icnocop/WinAppDriverBug
WinAppDriver.exe unexpectedly exits when the test is run in a TFS 2015 Update 5 on-prem build vNext agent (VsoAgent.exe) and an interactive console running in Windows Server 2019.
WinAppDriver.exe works without issues if I run vstest.console.exe on the command line interactively on the test agent.
It works fine in Azure Pipelines and AppVeyor.
I've tested with both WinAppDriver v1.1.1 and v1.2 RC.
In my case, the workaround is to just set the RedirectStandardInput
property of ProcessStartInfo
to true
.
🤷♂
@icnocop Thanks for sharing this workaround! This works great!
@LogicuL did you ever found a reason or solution? Started facing similar issue when we updated our surefire version to 3 from 2.20
I created a repository that can reproduce the issue here: https://github.com/icnocop/WinAppDriverBug
WinAppDriver.exe unexpectedly exits when the test is run in a TFS 2015 Update 5 on-prem build vNext agent (VsoAgent.exe) and an interactive console running in Windows Server 2019.
WinAppDriver.exe works without issues if I run vstest.console.exe on the command line interactively on the test agent.
It works fine in Azure Pipelines and AppVeyor.
I've tested with both WinAppDriver v1.1.1 and v1.2 RC.
In my case, the workaround is to just set the
RedirectStandardInput
property ofProcessStartInfo
totrue
.🤷♂
Could you share the Azure pipeline configuration, I am facing this issue in Azure pipeline and none of the above solution works for me.
I even tried using the WinAppDriver plugin but, still the same.
Update: I am using self hosted Windows 10 machine.
I'm also facing the same issue, could any one let me know Do I need to set the RedirectStandardInput property to true in Azure Pipeline? or my code? Appreciate your response.
Thanks
In the sample repo I shared, I launch WinAppDriver.exe
using C# .NET's Process.Start
method.
To fix the issue in my sample repo, it requires changes to the C# code:
ProcessStartInfo processStartInfo = new ProcessStartInfo(
exeFilePath,
commandLineArguments)
{
CreateNoWindow = true,
UseShellExecute = false,
RedirectStandardInput = true, // <-- this line will fix the issue where WinAppDriver.exe unexpectedly exits
RedirectStandardOutput = true,
RedirectStandardError = true,
StandardOutputEncoding = Encoding.UTF8,
StandardErrorEncoding = Encoding.UTF8
};
@icnocop Thanks for the response
I tried your code. I do not have start WinAppDriver step in the Azure pipeline .However, I am receiving below error .
Below is the code ..I am using.
string exeFilePath = @"C:\Program Files (x86)\Windows Application Driver\WinAppDriver.exe"; string commandLineArguments = $"{winAppDriverUri.Host} {winAppDriverUri.Port}{winAppDriverUri.PathAndQuery} /forcequit"; ProcessStartInfo processStartInfo = new ProcessStartInfo( exeFilePath, commandLineArguments) { CreateNoWindow = true, UseShellExecute = false, RedirectStandardInput = true, // <-- this line will fix the issue where WinAppDriver.exe unexpectedly exits RedirectStandardOutput = true, RedirectStandardError = true, StandardOutputEncoding = Encoding.UTF8, StandardErrorEncoding = Encoding.UTF8 };
Console.WriteLine($"Launching \"{processStartInfo.FileName}\" { processStartInfo.Arguments}");
Process.Start(processStartInfo);
Console.WriteLine("Started WinAppDriver");
@Karjun330 that seems like a different issue.
Check the std out and std error for relevant messages.
ProcessStartInfo processStartInfo = new ProcessStartInfo( exeFilePath, commandLineArguments) { CreateNoWindow = true, UseShellExecute = false, RedirectStandardInput = true, // <-- this line will fix the issue where WinAppDriver.exe unexpectedly exits RedirectStandardOutput = true, RedirectStandardError = true, StandardOutputEncoding = Encoding.UTF8, StandardErrorEncoding = Encoding.UTF8 };
@icnocop - Would you be aware of the JAVA equivalent for the same?
ProcessStartInfo processStartInfo = new ProcessStartInfo( exeFilePath, commandLineArguments) { CreateNoWindow = true, UseShellExecute = false, RedirectStandardInput = true, // <-- this line will fix the issue where WinAppDriver.exe unexpectedly exits RedirectStandardOutput = true, RedirectStandardError = true, StandardOutputEncoding = Encoding.UTF8, StandardErrorEncoding = Encoding.UTF8 };
@icnocop - Would you be aware of the JAVA equivalent for the same?
We were able to configure WAD on JENKINS using instructions here : #1368
I am having the following issue: I have a cake script that runs the automated tests on a virtual machine . The windows application driver is opened but it gets closed at the same time stamp that opens, something like this: **Windows Application Driver listening for requests at: http://127.0.0.1:4723/ Press ENTER to exit.
Exiting...**
Do you have any idea how to keep the driver running?
P.S. The developer mode is enabled on the virtual machine!