I have a test running on my Windows Agent. During the execution of test extra Software gets installed like an SQL-Server and drivers. After the test execution I would like to reset the state of the agent so that everything is clean and nothing is installed, like with snapshots in VMWare. Is this possible?
Related
i'm having issues to get a permanent active user-session on my virtual machine to execute gui tests developed with the functional testing tool Ranorex Studio via GitLab-Runner (Windows / Shell). The testsuite is based on a .NET solution which is built via MSBuild.exe and the output (bin/debug/*.exe) will be executed with some parameters via command line.
Procedure:
Start gitlab-runner via PowerShell as administrator with "gitlab-runner run" command
Make some changes in GitLab-Repository to start the pipeline via .yml-File
Ranorex test-project is built successfully and is starting the GUI-tests
In the first run the user session is active and the tests are going to be executed and interacting with the GUI, but when i try to trigger the pipeline again for further runs, the user-session turns to false and there is no interaction with the GUI (black sceenshots in test-report).
Already did:
Screensaver disabled
StandBy-Mode disabled
User-Access-Control on lowest setting
Lock-Screen disabled
Secure-Login disabeld
Remote connections enabeld
Ports openend
Keep Session open via .batch-File, when closing RDP-connection
GitLab-Runner Service => Log on with respective AD-User (equipped with admin-rights)
AD-User is alway logged in on virtual machine
With Jenkins (Master / Slave configuration) everything works fine
Would be grateful for any help!
Does your Ranorex process close down properly with an exit code? Does the Application Under Test also close down properly at the end? I am assuming something has locked - you could try a bit of Powershell to close the processes before a test run. One thing I had to do was keep the screen on - using a utility like 'Caffeine'.
We have a testing framework made in AutoIt for our Windows apps (older legacy apps that we will continue supporting). These have never been run on a schedule or part of CI (always been run manually). I tried to get some kind of auto run (or even just status reporting) out of the tests, with minimal luck.
I have a VM where the tests can run. I experimented with my own web app, which works okay locally for running and status reporting. But when set up on the server, AutoIt reports it cannot open the application. Same thing happens if I try to run the tests from a .bat file.
My current solution is to have AutoIt call my web app to report status (working okay locally, untested on the server), or to see if I can get AutoIt to report results back to TeamCity. I have the agent installed but when I run the build from TeamCity, AutoIt reports it can't launch the application. I tried this while logged into the VM, logged out, with RDS open; no luck.
Is it possible to run the tests manually from the VM and send results back to TeamCity? When I run them from TeamCity it reads the AutoIt output (which is in the expected format), but I need to let TeamCity know to update the results (so we can use TeamCity rather than my web app to show the results).
I may need to find a way to let TeamCity know a build has been started, which might then let it know to keep an eye on the process' output, but I'm not positive. Any ideas?
I solved this so it could be done more traditionally.
If anyone is confused by what "running the agent from the console" meant, it just means installing the agent without selecting the "as a service" checkbox, and then manually starting the agent by cd'ing to the BuildAgent/bin directory and running the command agent start. I also created a batch file that will do this automatically (but you must run it as admin).
Further, I found AutoIt couldn't do anything if the test doesn't run from the right directory, so I had to devise a solution to this.
The only issue now is that I have to have an old laptop always connected to the virtual machine the tests and app run on (since the AutoIt tests won't work without the VM desktop being interactive).
guys.
I'm having some trouble with TeamCity build agents.
I have an agent i'm using for calabash automation. When i'm running the build i'm getting :
Agent didn't come for the command in a 30 seconds.
I can see my agent in "Connected agents" tab, and "Disconnected" tab, and builds are not running. I tried to reboot the machine several times, and restarting the agent daemon on that machine, nothing happens, even when I shut down the machine it's still in "connected" and "disconnected" tabs.
There was a bug in TeamCity 9.1.x which is fixed in 9.1.4 which may cause such problem. You could use workaround from issue comments.
Im working with VS2010 and TFS and the Coded UI tests (CUIT).
I created some CUIT and added them to several Test Cases in Microsoft Test Manager 2010.
These tests are executed in our build-deploy-test steps.
This looks as follows (simplified):
Build application
Deploy
2a. Set snapshot of the Virtual Machine to which the application will be deployed to the snapshot in which the application is not installed
2b. Install application
Run tests
Step 3 contains Coded UI tests, but they cannot be executed (will fail), since there is no active remote desktop connection, which they need to be executed.
Now I would like to add a build step 2c. That automatically connects to the Remote Desktop so that the Coded UI Tests kan be executed.
How should I create this step in the Process Template?
I attempted this myself by running a PowerShell script to connect to a machine via Remote Desktop (see here to see how to use the Remote Desktop command-line utility).
This didn't really work for me personally because I was running this script from the build machine - which I could only connect to via Remote Desktop - and so when I close Remote Desktop it would close the session on the build machine and thus I would not be able to obtain a remote desktop connection with my test environment (plus it wasn't ideal to have to launch Remote Desktop from the build machine).
Therefore, the solution I went with instead was to enable auto-logon on the test environment (there are various ways to do this, I can't remember how I did it, but it's easily Googled).
So in my PowerShell script, which launched from our build machine, I used a command to remotely restart the test environment. With auto-logon enabled, the test environment would start back up with an active session, then I could carry on with Visual Studio Coded UI testing. This worked for me without any issues.
The command I used was something like this:
Shutdown.exe /r \\mytestenvironment
Here is some documentation for it.. If you intend on using this command to remotely restart a computer, don't forget to give your machine permissions on the test environment, otherwise this command won't work.
I then launched a command to sleep for a few minutes, to give time for the remote test environment to start back up again (with an active session), then I launched the tests.
Personally, I used a PowerShell script but you could also use a DOS/Batch script if you are more familiar with that.
Also, are you trying to run the automated tests as part of a build process template?
Let me know if you need any further help.
Our company produces cross-platform software and we have Bamboo instance which is building projects under various incompatible environments (linux, win, os x). There's a VM configured for building under each environment. So is it possible to run several remote agents on each VM to perform concurrent builds of different projects ?
Yes, that is possible. See the "Changing where the remote agent stores its data" section of the Bamboo Remote Agent Installation guide.
To make this work, for each remote agent you run on the same machine you will need to specify a different location defined for the agent to store its data (otherwise builds will fail trying to write to the same location).
Yes it is possible to run multiple remote agents on both windows and linux based hosts. I currently manage the remote agents for the linux hosts so I can't comment on the windows service remote agents.
I implemented the multiple remote agents buy first creating a folder for each agent, then on installation of each agent you specify the location for the bamboo.home of each agent.
On the bamboo master server you can rename the remote agent so you can tell the difference between the agent that is running you build job.
I can't comment on linux, but on Windows, yes you can.
If you change the Windows service name from the default 'Bamboo Remote Agent' to something like 'Bamboo Remote Agent 1', 'Bamboo Remote Agent 2' by:
uninstalling with the bin/uninstall-ntservcice
editing conf/wrapper.conf to change the service name and display name
reinstalling with the bin/install-nt-service
After doing this you should be able to run multiple agents fine.
I was able to create two agents on the same server. In this case I actually want the same bamboo-home set so that either agent can build to the same location ... just when some of my builds take longer, I have a second agent sitting around for the quicker builds that get queued up otherwise. In the bamboo-agent.sh, I changed:
APP_NAME, APP_LONG_NAME, and REAL_DIR
I didn't change anything in conf/wrapper.conf. And in the GUI I updated the name of the agents by clicking "Edit Details" on the agent capability page.
Just in case, I also made the agentUuid tag in bamboo-agent.cfg.xml empty thinking it would get overwritten when I started the agent. I didn't want to agents starting with the same Uuid even though I couldn't tell what this field was already used for.
As far as I can tell this worked as I expected. I could see two agents from the GUI and kicked off two builds simultaneously. FWIW, what I don't know if this is considered a hacked way of doing this or not.