When I run my selenium test (mvn test) from jenkins (windows) I see only the console output. I don't see the real browsers getting opened . How can I configure jenkins so that I can see the browsers running the test?
I had the same problem, i got the solution after many attempts.
This solution works ONLY on windows XP
If you are using jenkins as a windows service you need to do the following :
1) In windows service select the service of jenkins
2) Open properties window of the service -> Logon-> enable the checkbox "Allow service to interact with desktop"
After then you should reboot the service jenkins
Hope this help you :)
UPDATE:
Actually, I'm working on a an automation tool using Selenium on Windows 10, I've installed Jenkins ver. 2.207 as windows application (EXE file), it's running as windows service and ALL drivers (Chrome, FireFox, IE) are visible during test executions WITHOUT performing a mere configuration on the System or Jenkins
I got the solution. I ran jenkins from command prompt as "java -jar jenkins.war" instead of the windows installer version. Now I can see my browser based tests being executed.
If you are already doing what #Sachin suggests in a comment (i.e. looking at the machine where Jenkins actually runs) and still do not see the browsers, then your problem may be the following:
If you run Jenkins as a service in the background it won't open apps in the foreground. You may either try to run it not as a service in the foreground, or run it as a Local System account and check Allow the service to interact with desktop option. In the latter case you may get into permission problems, though.
Update: To make sure this answer is understood properly by others: Jenkins Windows 'native' installation is not really native. It's a wrapper around Java that runs it as a service.
To interact with desktop GUI, you should launch slave agent via JNLP:
https://wiki.jenkins-ci.org/display/JENKINS/Distributed+builds#Distributedbuilds-LaunchslaveagentviaJavaWebStart
After adding the node in Jenkins (configured as Java Web Start launch), just make a startup batch script on the node machine:
java -jar slave.jar -jnlpUrl http://{Your Jenkins Server}:8080/computer/{Your Jenkins Node}/slave-agent.jnlp
(slave.jar can be downloaded from http://{Your Jenkins Server}:8080/jnlpJars/slave.jar)
See more answers here:
How to run GUI tests on a jenkins windows slave without remote desktop connection?
In the case of Windows 7 you should not install jenkins as windows application (because in this recent version, Microsoft decided to give services their own hidden desktop even you enable the functionality "interact with desktop" in jenkins service), you may have to deploy it from a war file as follows:
1) Download jenkins.war from Jenkins official site
2) Deploy it by the command prompt : java -jar {directoryOfJenkinsFile}/jenkins.war
3) Now you can access jenkins administration on http:// localhost:8080
Hope that helps you !
this is an issue for Jenkins. on Windows it is possible to access logon user's session (screen) under system account. to make the UI testing visible, Jenkins needs to bypass UAC (user access
control) at background. this solution works for me with my own service running as system account.
I also faced the same issue earlier in my local machine (Windows 10).
My test was running perfectly from the NetBeans but when I moved to Jenkins it was only running in console mode. I was unable to view the UI.
So for that, you just need to make your local machine as a Jenkins slave by creating a new slave node in your Jenkins and select that node to execute the Jenkins job.
If jenkins installed by windows installer it is showing only Console out put only. To see browsers download jenkins.war file and run java -jar jenkins.war from command line.
Go through this site:
http://learnseleniumtesting.com/jenkins-and-continuous-test-execution/
If you have the following situation,
You are able to login to the remote machine
You don't see the Jenkins agent window
This slave machine is accessed by many users then try the following,
then try the following suggestion.
Login to slave machine
Go to Task manager
Users
Logout all the users
Then login again.
This worked for me.
Related
I have this setup to change the URL to 5002.
After running, this the result.
From our friends at MS support:
"IISExpress uses http.sys for its communication and it requires SSL ports to be registered as Administrator. To avoid running Visual Studio as administrator, IIS Express reserves the port range 44300 - 44399 when it is installed. As long as you select a port within this range (which is what VS does) you do not need to run IISExpressAdminCmd to register the URL."
via support link: https://developercommunity.visualstudio.com/content/problem/39430/changing-port-number-in-a-web-project-does-not-imm.html
Solution #1 Use IIsExpressAdminCmd.exe to register the URL
From cmd prompt go to directory
C:\Program Files (x86)\IIS Express
Run IISExpressAdmiCmd to register the url
IisExpressAdminCmd.exe setupsslUrl -url:https://localhost:5002/ -UseSelfSigned
Solution #2
Run VS under admin context
Solution #3
Switch the port to a pre-registered one 44300 - 44399
A few things to try;
Search through your project code (using find all) looking for
instances of "5002" or whatever your port number was previously. You
will be looking for references in generated code rather than code you
have created yourself.
Try with a difference browser (Chrome / Firefox etc).
Shut down any other running applications.
Try running without https. If this works you can focus your effort on getting the developer certificates working.
Stop and start visual studio (its annoying how often this solves anomalies!)
Check that the IIS express instance is running in the tray - click on the tray, locate the respective running application and
click browse.
Create a completely clean application using port 5002 and compare the two solutions to relevant differences.
Reboot and try again - in case there are any other applications locking this port number.
I'm running a .Net Core microservice on Linux (Ubuntu) and am trying to remote debug with Visual Studio over SSH. But the service is run under the user svcuser and my user is mainuser. Main user is in the same group as the service user.
In visual studio, I can see the process that the service is running under, but when I try to attach I get:
One or more errors occurred. Failed to attach to process. The .Net Debugger has insufficient privileges to debug the process. To debug this process, vsdbg must be running with root permissions.
I checked in MS documentation but for Linux all they have is this: https://learn.microsoft.com/en-us/visualstudio/debugger/remote-debugging-dotnet-core-linux-with-ssh?view=vs-2019 which has no info on running the service with a different user
And the only info they have on fixing such a problem is for windows only: https://learn.microsoft.com/en-us/visualstudio/debugger/error-the-microsoft-visual-studio-remote-debugging-monitor-on-the-remote-computer-is-running-as-a-different-user?view=vs-2019
If you have sudo privileges then this is relatively easy, and can be kept secured to those users with sudo privs. Avoids needing to reconfigure users/environments, and allows you to debug any process on the machine regardless of which user account it is running as.
If you use Visual Studio to make an initial attempt to debug you will find that a ~/.vs-debugger folder has been created in the home directory of the user account you were attempting to use. This command will help you locate the vsdbg binary which was installed. You can install VsDbg manually but I find leveraging the automated process is easier. If you are using VSCode this becomes a manual process, and an exercize left for the reader, but I would still use VS2019 IDE to prep the target just to keep things consistent between tools.
find ~ | grep vsdbg
For my installation the binary is located at ~/.vs-debugger/vs2019/vsdbg and this path will most likely change over time.
First, rename the binary to something convenient:
mv ~/.vs-debugger/vs2019/vsdbg ~/.vs-debugger/vs2019/vsdbg-bin
Second, create a script to replace the binary:
touch ~/.vs-debugger/vs2019/vsdbg
chmod 770 ~/.vs-debugger/vs2019/vsdbg
nano ~/.vs-debugger/vs2019/vsdbg
The script content might look something like this, note the full path to vsdbg-bin, the use of $# ensures all command-line args passed to your script are forwarded to VsDbg.
#!/bin/bash
sudo ~/.vs-debugger/vs2019/vsdbg-bin $#
Now retry your debug session from Visual Studio, if you did things correctly you should be able to attach to any remote process on the target machine using SSH->VsDbg. "Works on my machine." ;) This was confirmed with VS2019 16.8.4, .NET 5.0, and VsDbg 16.9.20122.2 debugging an ASP.NET Core application running on Debian 5.4.8 (x64) launched by systemd under a service user account in Azure. "Sweet."
HTH!
I have created a windows application using c# VS express 2012. The app works great in the VS environment. I have published the application using VS(ClickOnce) to the Desktop as an offline application, which does not check for updates. The app is not signed and security is disabled. The application seems to install fine when I run the setup.exe file. However, when I try to run the program from the start menu nothing happens. In the task manager, a process for the application appears for a few seconds then just goes away. The app window doesn't show and there aren't any indications of an error. If I navigate directly to the .exe of the app (%userprofile%\appdata\local\apps\2.0\%random id%......) and run it that way, it starts up and appears to function as designed. I've done some research and found that certain drivers and software (if installed) will cause this behavior (i.e. Kensington Mouse driver and Provencia software(?)). I've checked and I do not have either of these installed. Any help with this will be much appreciated.
Thanks in advance.
I'm trying to set up CruiseControl.NET (1.6)
The installation completes successfully, however i cannot seem to start the actual service.
When running the CCNET.exe i get a console window that the last thing it writes is: Initialising Security.
Running the service from service control manager also does not work..
Trying to access localhost/ccnet returns no response.
What am i missing here? I have installed the product in the past with success, not sure what is wrong this time.
#lysergic-acid - Even if the main config is done (server/ccnet.config) and you are running it from a command prompt, you won't see the web dashboard yet.
If you are installing on IIS7, the setup process for the web dashboard requires steps that aren't in the CC.Net webdashboard setup docs in sourceforge.
What got me working was this CC.Net web dashboard installer page, which is from the Confluence site, rather than the source forge site: http://confluence.public.thoughtworks.org/display/CCNET/Installing+the+Web+Dashboard
In the comments area, there are specifics about IIS7 (I'm assuming that's part of the problem).
I am still having trouble with the service, so I can't help you there, but you can definitely run the web dashboard without the service as long as the cmd prompt version is running.
The setup of the virtual directory for the web front-end might of not completed successfully. Try using the IIS Service Manager to create an application around the Service folder. I think there's an issue with the install if you forget to unblock the download, but I haven't fiddled with it enough to be sure.
Keep in mind that the web front-end and ccnet service are two totally isolated pieces. You should be able to see the web front-end even if the ccnet service doesn't run.
I had trouble one time when installing it and IIS was set to disabled (and thus was not running), I had to uninstall CruiseControl.NET, start IIS and then reinstall CC.Net.
Do you have a firewall that blocks ports? The default port is 21234.
You need both the web part and the service part installed to be able to run CC.Net.
I am using VS2008 C# and testing on my local XP Pro PC with local IIS, I have wrote a web service to call a third party software .exe file to use svn checkout commands to insert data into a folder, which use System.Diagnostics.Process.Start . The same codes did work when I use VS2008 build-in ASP.NET Development Server(http://localhost:2999/MyServices/MyServices.asmx). but when I use IIS normal URL(http://developer/MyServices/MyServices.asmx) to run Process.Start on the web service, it just haunlted and not doing anything.plz send one sample program.
This is most likely down to the user being used to run the code. When using the built-in server, it is running as the same user as Visual Studio is running as. When in IIS, it will be running as the MACHINENAME\ASPNET user.
If the process you are starting cannot execute as the MACHINENAME\ASPNET user, it will not work when hosted in IIS unless you change your configuration to change the user it runs as. See this page for more info on what users are used for what in IIS.