I have to stand up a azure pipeline agent for running UI tests that runs "As an interactive process" instead of "As a service". Servers running UI Tests are already prepped for self logon and always on. Can i install the agent on the same server as where the tests are being run?
I believe you have checked this document about how to configure the self hosted agent to run UI test.
I have installed an agent on VM and i can run UI test successfully on the VM.
If UI test can run on the machine where the agent is installed, I think it can also run on the server that runs the UI test, if the agent is installed on the server.
Related
i'm facing a problem with VSTS agent state is offline i installed the agent through cmd under the right pool and downloaded after that but it still offline any help please ?
If the build agent is running as interactive mode, you need to start agent by running run.cmd file:
Open Command line as administrator
Run run.cmd file (under agent folder)
If the build agent is running as service, you can check whether the related service is running in Services.
I've started using Azure Pipelines, and my django application runs tests which require a local PostgreSQL server.
I'm pretty stumped as I cannot find any information in the MS documentation for how to change the agents configuration to include a local PostgreSQL server.
It seems like a very simple thing to do but I cannot seem to find the relevant documentation. Looking at the agent pool information it lists MySQL as being installed locally.
How can I include a local PostgreSQL server in the configuration of the agent that will build my application and run tests?
Some options:
Create a Docker container with your testing prerequisites in it, and then run your tests in the container
Create your own self-hosted agent and install whatever software you need on it, and then use that instead of the Microsoft-hosted agents.
As part of Integrating the TOSCA (Automation tool) in the release pipeline, we are unable to kickoff the IE browser.
If you are using hosted agents then it's not supported, you have to run the agents in interactive mode for the UI related things.
So just try to deploy an private agent and run the agent in interactive mode, please see Deploy an agent on Windows for details.
My protractor tests work fine on my local machine and on Azure VM Windows Server 2012R2 when accessed via RDP. I explicitly set browser window resolution in my tests using browser.driver.manage().window().setSize(1600, 900); and it allows tests to work properly.
However, when the VM mentioned above is used as build machine, controlled by VSO (VSTS) agent, my protractor tests are failing. I suspect it happens because screen resolution for VSO agent session is smaller then desired resolution specified in my tests and WebDriver(ChromeDriver) can't set resolution higher than OS limitation.
My question is how to change screen resolution of Azure VM for VSO agent session?
I tried custom utility for changing screen resolution from here
and it works on my PC, however when it is executed by VSTS agent on Azure VM it throws error:
System.InvalidOperationException: The display driver failed the specified graphics mode.
In order to run the protractor tests, the agent needs an interactive session. Configure the agent to run interactively, instead of as a service.
It did help to run agent in interactive. When I connect to my build machine via RDP it gets screen resolution of my client machine. Then when I launch vso agent and disconnect by RDP, this display resolution remains on build machine, so selenium can maximize browser window.
I'm setting up a build definition in Visual Studio Team Services using a Build Agent installed on my local machine for testing.
I'm following these instructions for creating a build agent, setting up a build definition, and queuing a build. I've created the agent on my local computer and it appears in the agent pool in VSTS. The agent is enabled and ready to go. I've also created a build definition that invokes my build script. Everything up to this point appears to work fine.
At this point I'm ready to queue a build and run it. The dialog for this looks like:
The dropdown labeled "Queue" only shows the Hosted agent pool. There should be a second pool called Default but it is not appearing. I can get it to "appear" by right clicking and inspecting the HTML and then using dev tools to change the value for the Hosted option. Hosted's ID is 2, I changed it to 1 since I assumed this to be the ID for Default. Once I do this I can click "OK" and the build runs as expected -- everything is checked out on my local machine by the build agent. Presumably my assumption about the ID value is correct.
So...everything it working correctly once I muck around with the plumbing a bit. But this is definitely not the way things should be working. Why is the Default queue not showing up in the dropdown? Do I need to flip a switch somewhere to make it work? Does my account not have enough access?
Some other details:
My account is a "Pool Administrator"
The build agent is not installed as a Windows service. I start it manually from a command prompt. I've not been able to install it as a service.
The machine that has the build agent installed on it is running Windows 10 x64 Pro. It was upgraded from Windows 8 x64 Pro.
I cannot use a hosted agent as I'm building a Unity project and Unity is not supported by for hosted agents.
I know I can use Unity Cloud Build but I do not want to.
UPDATE
I've removed my previous Build Agent and installed a new one, as a service, on a Windows Azure VM running Windows 10 Enterprise x64. With this change the "Hosted" and "Default" queues are appearing as expected.
Your account needs to also have access to the agent queue. Agent pools and agent queues are different entities, and being a "pool administration" does not necessarily mean you are a "queue administrator".
In my case it helped to execute the agent configuration in a console with elevated/administrator rights. If the agent configuration is done in a console with normal rights, the agent can still be configured properly, but its queue won't appear for selection when you will be queuing a new build.