I've a Windows Server 2012 R2 based Hyper-V Host, which contains a Windows Server 2012 R2 VM as a VPN using RRAS and another VM running Debian plus the Jenkins (latest version) master server. Using this VPN, a private hosted Windows Server 2012 R2 VM act as Jenkins slave using those VPN connection. For better distinction, call this one node1.
This is bascially working as expected, but there is a problem: Sometimes, when I start a buildjob on node1, it hangs. Only the first 2 steps (Started through user XYZ and Build on slave node1 in workspace C:\jenkins are shown in the log, then nothing happens. On the master, the node1 is shown as online and is connected to the VPN.
Currently I start Jenkins using a windows task. Using this method, the above happens only sometimes. But as I configured the server, I tried to solve this in a cleaner way by registering Jenkins as Windows Service. As Windows Service, I had the same behavior: In the web panel Node1 is shown as online, but when I start a job on it I only come to Build on slave node1 and then it stops.
Normally the next step should be fetching the latest source code from my git repo. I already had the problem but now found out that it has something to do how Jenkins is started. But for me it seems very strange because running the slave as a Windows Service hasn't worked at least one time, and by running it as a Task it works most of the time.
I only found out that the problem also occurs when I start a job directly after node1 boots. When I then cancel the hanging Job and start it again, it seems to work for a while.
There are few options that I can think of them. According to Jenkins Wiki
If the slave is supposed to start desktop applications you have to
allow the service to interact with the desktop
(Action->Properties->Logon->Allow service to interact with desktop).
Another option can be that Windows services don't have the ability to interact with the windows desktop, meaning that some UI tests might no work as you expect. Do any of the steps may need interacting with the desktop (Windows GUI)?
Just for the sports how about to setup a temporary clean windows server to act as node2 (Jenkins slave) and to check if the problem is been reproduced?
Related
I know that Ansible uses winRM to connect to window hosts, which means it does not fully load a windows profile when connecting to a host, but rather can execute bat/powershell commands remotely.
But is there a method where I can logon as a complete Windows profile using Ansible.
My requirement is that every Monday morning I want an automated job (Preferrabley Jenkins -> Ansible) that will logon to my Windows Server machines (around 10 machines). Currently we have a support team that does this every Monday morning (because the machines are rebooted every weekend), and sometimes 1 or 2 machines are missed out, and I would like to automate this because we have Scheduled Tasks that are supposed to run early in the morning, that sometimes misses to run because support forgets to login to a particular machine.
There are 2 connection plugins for Windows in Ansible PSRP and WinRM. Whatever tasks your support team is performing manually can be automated with Ansible Windows Modules or Powershell commands. Though they are executed remotely, actions are performed on the target servers only.
I have a Windows 10 Pro VM, that I want to run a Localhost Katalon Agent on.
I have it running successfully, but I would like for it to start when the computer starts.
Right now, I have it running by putting a Shortcut in the Startup folder. But this only gets triggered if someone logs into the machine.
How do I get the Agent to start when windows startup, even if no one logs in?
Come to find out. the Katalon Agent comes with NSSM. I was able to use that to create a Service using these instructions: https://stackoverflow.com/a/26626771/4739712
To test our desktop application we have a Master project that runs the Slave project on different VMs.
We are using TeamCity to start our tests. On a TestManagement machine (VM) we have a Build Agent that is running as Service. This Build Agent starts the Master project with TestExecute.
This project connects with RDP to different VM to run our UI Tests (Slave project) of our App. We are using Network Suite and run our tests on Hosts (VMs) like it is suggest here: Using Network Suite.
But we have an issue with the screen resolution that is used to run our UI Tests. The resolution is too low.
This page Running tests via RDP gives an explanation:
"When running tests on a remote computer that participates in distributed testing, TestComplete creates a Remote Desktop session and automatically sets the master computer's screen resolution on the remote computer. This is done to avoid possible problems with test running."
So TestExecute will use the master computer's screen resolution.
But TeamCity Agent is run as a service on a VM (TestManagement machine) and there is no screen resolution because it's an headless machine and not like a real user that will connect with RDP to this VM and start the Master Project.
I assume TestExecute will then use the default screen resolution (something like 640x480) as the resolution for the RDP connection. But this is too low to run our tests, some object are not on the screen and we have many issues...
Is there a way to change the resolution used by the RDP connection that TestExecute / TestComplete will create ?
The tricky part is that the Master project is started from a service on an headless machine...
Thank you for your answers,
Camille
In the past, we experienced a similar problem as yours and we were unable to solve it by this way. As solution (right now working for us) we installed into our test environments the TightVNC. This able us to forget the screen connection (RDP issues) because you configure the screen resolution by RDP the first time, then access via IP, log in and you will be able to launch whatever you want without open any application.
Maybe its not the best solution but for our testing environments we can launch tests from Jenkins on demand without screen resolution problems.
I'm trying to introduce continuous integration in an old project, and we've got quite specific situation - it's possible to put the CI server only on our test server that runs on CentOS. The server has quite a lot of unused RAM and CPU capability.
However, we need to run Ant builds on Windows (this also used to be how the project did packaging before), however it turned out that not the same output (after binary compare) is produced by just using Unix versions of Java and Ant.
I drew up a diagram of how in my mind it could work, but I'm really wondering whether that is even possible (with already given tools).
The black part is implemented, I'm curious whether the red part could be possible. Could the Jenkins slave communicate with master on different OS?
It should be possible. I have a feeling you will need to play with your network settings. But if before you start changing anything see if you can start a headless slave by following these directions: https://wiki.jenkins-ci.org/display/JENKINS/Step+by+step+guide+to+set+up+master+and+slave+machine
Using VirtualBox for CentOS, it will possible to run a Windows VM on your CentOS host.
I'm not sure you need Docker to launch your Jenkins slave.
It maybe better to use a standard JNLP Windows service to connect your Windows slave to Dockerised Jenkins master.
If the master is not able to view the Windows node using this method, you may have to tweak your network configuration on the Windows VM.
But I'm not sure it's necessary.
My Window Tester UI Tests(All the tests which has error dialogs and error messages in in RCP Application) are failing in Jenkins server, but they are passing in my local machine.
Is there anything to do with machine configurations, like based one executors?
if the machine configurations doesn't matter why they are not failing in my local machine?
You are probably not running your Jenkins server in a desktop session, meaning that it does not have access to your GUI (e.g. it can't launch anything that pops-up a window or a dialog).
So you either need to start the Jenkins master manually from the command line or allow it to access the GUI if it's run as a service.
See also these two related topics:
How to run GUI tests on a jenkins windows slave without remote desktop connection?
https://serverfault.com/questions/285065/gui-tests-in-hudson-jenkins-on-windows