I am wondering how VSTS hosted agents provisioning works in terms of state. Does a hosted agent get reassigned from one job to another without being 'snapshotted' back to a 'clean' state? Or does it carry around the remnants from previous builds?
Thanks
There won't has any data 'leakage' between different subscriptions to use Hosted agent, even you build the same build definition for twice, you can not get any data from first build to second build.
That's why Clean option is not relevant when you use Hosted agent, and you can find Clean the local repo on the agent section:
Note
Cleaning is not relevant if you are using a hosted agent because you
get a new agent every time in that case.
Hosted agents are single-use only. They are not reused between builds.
Related
We are running Azure DevOps Server and we have our own, locally hosted build agents. I'm trying to get a WhiteSource scan to run on one of our build agents. The WhiteSource task "demands" node.js. But none of our projects use node.js at all, so whether the agents have node.js installed is totally irrelevant. I can't identify an option that could be used to stop the WhiteSource task making this demand.
Is there a way to cancel the demand? A way to tell ADO "this task/pipeline is going to demand node.js, but in fact I know better; you may disregard that demand and run the pipeline even on a build agent that doesn't have node.js installed"?
The build pipeline is a YAML pipeline. I would like a YAML-only solution if possible.
I would like to avoid actually installing node.js on our build agents, given that the dependency on it is entirely spurious; it would never actually be used.
Is there a way to cancel the demand?
The demand of some agents is automatically added according to the needs of the task.
In this case, we cannot cancel these demands.
For a workaround to solve this issue, you can manually set the node.js in Agent Pools -> Target self agent -> Capabilities -> User-defined capabilities.
It can also meet the demand of the pipeline without actually installing node.js.
We use Azure DevOps Server 2020 on prem. We are not in a position to move to Services. We are not in a position to use agents in Azure, because these agent would not be able to talk to the server, which is behind the corporate firewall.
So, we are stuck with on-prem agents and this suffocates us. Our app is a monolith in the worst sense of the word. Its PR build takes time and is extremely hungry on resources. Currently we have 2-3 PR builds running concurrently on the same machine and it takes eternity. In short - it is very bad.
On the other hands, developers have pretty powerful machines. Of course, I do not want my machine to serve PR builds of others, but if it could run my own PR build, that would be fantastic.
Alas, I do not see how this can be done. So, my question - is it possible to configure Azure DevOps Server 2020 so that PR validation build for a PR submitted by Alice would run on the build agent running on Alice's machine and only if there is no such agent would it pick up a "standard" build agent running on a build server?
Clarification
Although the question speaks about Alice, but there are also Bob and Charlie and Deepak. About 300+ developers. So, the solution should not assume there is only one developer working on the code.
is it possible to configure Azure DevOps Server 2020 so that PR validation build for a PR submitted by Alice would run on the build agent running on Alice's machine
We could install the self-hosted agent in the Alice's machine, open Organization Settings->Agent pools->select the agent->click the tab Capabilities->search the field Agent.ComputerName, then open PR build definition and add Demands, such as below.
Then the PR build will run with the specified agent, you could check this doc: Specify demands
for more details.
In addition, if the PR build does not find the matching agent, the build will not run with another agent.
Update1
Each developers have their owner agent on their owner’s machine, right?
Check this doc: predefined variables, it contain the variable Build.RequestedFor and Build.RequestedForEmail, if the pipeline is pull request trigger, it will show the pull request creator name and email, add this to the pipeline Demands. Such as
And then, let all developers add capabilities to their agents, such as TriggerName = {their email or display name}. Since I am using the variable Build.RequestedForEmail, in my agent, I add the capabilities:
Then if I create a pull request, the build will run via my own machine agent.
Update 2
For example, the original PR build name is A. Open it and add default demand(you could add anything)
Add new build definition name B, add task power shell and enter power shell script to call below REST API to update the A definition
Definitions - Get
GET https://dev.azure.com/{organization}/{project}/_apis/build/definitions/{definitionId}?api-version=6.1-preview.7
Definitions - Update
PUT https://dev.azure.com/{organization}/{project}/_apis/build/definitions/{definitionId}?api-version=6.1-preview.7
Then add build B as pull request build.
Update3
is it possible to configure Azure DevOps Server 2020 so that PR validation build for a PR submitted by Alice would run on the build agent running on Alice's machine and only if there is no such agent would it pick up a "standard" build agent running on a build server?
If the "real" targets the build agent initially, then what happens when the auxiliary one determines the dev has an individual agent?
The real build definition has demands, If the build runs by default demands, it will run the standard build agent.
The auxiliary one, we need to add condition to run the power shell script to update the real build demands. if Alice's machine has matching agent, it will update the real build demands, and then the real build will run the Alice's machine agent.
We are unable to run any release becouse of the following message:
Your account has no free minutes remaining. Add a hosted pipeline to run more builds or releases.
I guess this happend becouse one of our build was using the hosted version and not the private pipeline.
The problem now is that we cannot run any builds. The builds are running fine (on local agents) but we're unable to run any releases.
How can we modify the release definition to use a local agent?
Thanks for any help
You can choose the agent queue to use for a release within the Phase view within an environment.
A release has environments. An environment can have multiple phases. Each phase can run on a different agent queue.
This sounds like a licensing issue to me. VSTS Release pipelines are a paid product. You get 1 hosted and/or private pipeline free each month, but after that you pay for each one. Hosted pipelines are also limited to the number of minutes you can execute them (You get 240 free minutes).
Check out this page for additional details and make sure you are licensed up.
Also, if you have Visual Studio Enterprise licenses, these will grant you extra pipelines per user.
I have a local VM that has successfully been running builds from VSTS.
After the builds are completed I have a deployment job that pushes my artifacts to a number of servers. This has been working fine for the past few months.
This morning, I received a message that I was out of "deployment minutes" and my deployments failed, however my builds completed.
Obviously it was building locally, but deploying in the cloud.
Is there a way I can configure my agent or my deployment job within VSTS to use my local agent?
You should just be able to switch your release definition to use the same agent queue as your builds. In each environment, click on each phase and change the agent queue it uses from "Hosted" to whatever you named your local agent queue.
You may need to install additional software (Azure PowerShell, if you're deploying to Azure, for example), but it will work the same -- the build and release agents are exactly the same software and use exactly the same tasks.
You should be able to add your agent to the pool (it requires some software installed there of course) and then select it instead of a hosted environment in the deployment step configuration:
Agent pools
At the bottom you can find:
The hosted pool provides all VSTS accounts with a single hosted build agent and a limited number of free build minutes each month. If you need more hosted build resources, or need to run more than one build concurrently, then you can either:
- Deploy your own on-premises build agents
- Buy additional hosted pipelines
Here is where I finally found the option to specify which agent the release should run on:
I have a Windows VM that hosts a VSTS build agent. Due to the number and length of builds that are running I would like to know whether multiple build agents can be hosted on one computer? That would allow a dedicated agent for slow builds, and a dedicated agent for quick builds.
https://www.visualstudio.com/en-us/docs/build/admin/agents/v2-windows
Yes you can run multiple agents in a single VM.
Make two directories say Agent1 and Agent2, extract the agent in each one of them and configure them with different names against your VSTS/TFS account.
It should work out of the box.
We run 4 agent jobs per machine concurrently with no issues. As mentioned above, should work out of the box. Just make sure you clean up directories. We have a script to do it every night
Yes, this works, I did the following:
Created a PAT for agent installation needs
Downloaded agent binaries from the agent creation page
Unpacked the archive contents into 2 different directories ("c:\ado-build-agents\agent1" and "c:\ado-build-agents\agent2")
Ran "config.cmd" and followed configuration instructions, provided by it.
Updated pipelines to build the agent pool, which those agents reside in ("Default" in my case)
To test the setup - triggered all 15 pipelines, that I had. As the result I was able to see two pipelines running at the same time, while others were in the "Queued" state (according to my expectations).
I will be also testing out how resources are consumed by the agents to try to understand if I should deploy more agents on the build machine.