Im using VSTS controller agent setup to run a load test of a Web Application. I have 3 machines configured for this RIG setup. My machine (MACHINE 1) is configured as one Controller. Apart from my machine, I have another controller machine (MACHINE 2) and one Agent machine (MACHINE 3).
I'm giving the control from my machine (MACHINE 1) to another controller machine (MACHINE 2) where the agent machine (MACHINE 3) is been added. I can see the agent machine and the controller machine added to my controller machine.
The problem is that, the agent machine in the "Agent Pane" through visual studio "Manage Test Controller" menu in DISCONNECTED. How can I make it to "Online" so that I can run the load test.
I have posted the same question in the MSDN forum where I got certain aspects that I have to check while configuring the RIG-controller and agent setup. With the help of the reply's in the MSDN forum I have make the RIG setup work. Can refer the following link if you too are facing the problem as I did.
Aspects to be checked while Configuring VSTS RIG Setup
Related
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 just wondering on how to assign a different machine/server as a build agent in TeamCity.
Any help will be greatly appreciated :)
Installing a new build agent is a fairly straight forward process.
If you access your teamcity site (http://teamcity) through a browser from the target build agent machine (the windows 2008 server in this case) then you can download the installer directly to that machine.
Navigate to the administration section and click on Install Build Agents
Click on MS Windows Installer and download the agentinstaller.exe
Start the installer and ensure you are installing a windows service
Enter your destination directory for the build agent - This is where the working directory and configuration will reside, and click next to perform the installation
You then need to provide details of you TeamCity server so the agent can communicate back to the server. Enter the correct url of the server and choose a name for this agent and click save
Run the agent under the SYSTEM account for now, unless you have a dedicated network account (recommended) and start the build agent service
You will now need to enable the agent inside of the TeamCity UI (this may take a few minutes to appear). It will first appear as unauthorized and you'll have to wait for it to upgrade and reconnect.
Once this has happened, you can authorize the agent by clicking the Authorize agent button. A dialog will popup where you can enter some notes if required.
TeamCity Documentation - Installing via MS Windows Installer
There are limitations on the number of agents you can have under you license so you may need to purchase an additional one, but I suspect in this case you'll be okay - TeamCity Licensing
Hope this helps
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?
I have an entry in my hosts file that points somesite.com to 127.0.0.1 (localhost) so that I can test certain aspects of my web app (i goto http://somesite.com in a browser to test). Can someone suggest a way to debug a setup like this (in visual studio) that does not include using http://localhost?
I understand that this can most likely be done using remote debugger, if that is the best way can someone explain how thats setup (or a link to a good article).
Set up a virtual machine, and run the web app in the VM. If you have two network adapters in the machine, you can even set things up so the network traffic goes out one, to a switch, and back in the other to the VM (I've done this sometimes so I could capture the traffic with WireShark).
I have two machines in two different domains. On both I have VS 2005 installed. I want remote debug between them. Without authentication it is possible but I want to debug managed code. I don't want to debug directly since it is really crappy machine.
When I try to attach with debugger I get message "The trust relationship between this workstation and primary domain failed." Any idea how to overcome this ? I tried tricks with adding same local username on both machines but with no luck.
EDIT: I have same local users on both machines. I started both VS2005 and Debugging monitor with RunAs using local users. I turned Windows Auditing on debug machine and I see that local user from VS2005 machine is trying to logon. But he fails with error 0xC000018D (ERROR_TRUSTED_RELATIONSHIP_FAILURE)
Gregg Miskely has a blog post on this. You might get it to work if both local accounts have the same user name and password. You might also try dropping your good box from it's domain so that you are going from a workgroup to a domain rather than domain to domain.
I seem to remember that I have sometimes found it useful to use RunAs when you run msvcmon (or whatever it's called this week - the remote debugging stub anyway), to force it to start as the user which you have set up to be the same on both machines.
I would guess that on the machine you're running VS on, you will also need to log in as the local user rather than a domain user (or start VS with RunAs).
I have never understood why this needed to be so hard, given that unmanaged debugging is so much easier, and must expose every security hole that managed debugging could.
The blog post wasn't totally clear that this would work, but I was able to run Visual Studio as my domain account and still debug a process on a machine that was not on a domain.
I have a physical development machine PHYSICAL on a Active Directory domain DOMAIN. I'm logged in and running Visual Studio as DOMAIN\employee.
I have a virtual machine VIRTUAL that is not attached to an Active Directory domain at all. This is the machine running the process I want to debug.
Like the blog post says, create local accounts PHYSICAL\employee (on PHYSICAL) and VIRTUAL\employee (on VIRTUAL). They both must be Administrators and have the same password as DOMAIN\employee.
The remote debugger and the process to debug must be run on VIRTUAL while logged in as VIRTUAL\employee. Then on PHYSICAL while logged in as DOMAIN\employee I can use "Attach to Process..." and connect to VIRTUAL to get a process list.