I've configured the 2 build agents with the different version in single Agent pool to suit our developers.
I've configured the Maintenance Job in order to keep disk clean. Everything works properly for Agent 2, but old work files on Agent 1 are not deleted.
From the log:
No agent found in pool DX which satisfies the specified demands:
Agent.Name -equals "Agent 1 name"
Agent.Version -gtVersion 2.114.0
It looks like the maintenance job will clean the work folders of an agent that are the same version. Does anyone have any idea how to proceed? Or is there any problem with our configuration?
Further details:
Agent 1 Version 1.105.6
Agent 2 Version 2.117.2
TFS Version 15.117.26714.0
To narrow down the issue you could try below configuration
Agent Pool with two Agent 1 Version
Agent Pool with two Agent 2 Version
This will narrow down if the issue is related to your build agent version. Maintenance Job may not support with build agent version 1.
Besides, none of your build agent version is 2.114.0, why your log is trying find agent version 2.114. This also could be a cached related issue, please double check it.
Related
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.
I'm trying to find the manual intervention task in the release management of my on Prem- TFS
As per here this is available in TFS 2017. By May it's removed in the latest release?
I searched through the TFS marketplace, but no luck so far.
My TFS Configuration is 16.122.27319.1 (Tfs2018.Update1.RC1)
Could somebody help me to get this task in my release definition?
There are 3 types of phases or ("jobs"):
Agent
Deployment Group
Server (or 'agentless')
Manual intervention goes in a Server/agentless job. You probably have a standard Agent job in your release definition. You'll need to break your release up into multiple jobs: Agent (up to the point where you need a manual intervention), Server (containing the manual intervention), then Agent again.
We have 1 Team Foundation Server 2017 Update 3 and 3 different build agents configuered. I've noticed that TFS picks the same build agent after when a project have to build. My question is there an option to pick a build agent randomly?
Unfortunately there isn't an option to set that to pick a build agent randomly.
For now, in TFS 2017 it picks the agent in the order that they are registered if the agents are all idle when a build is queued, rather than randomly selecting an agent.
Set Build Agent Priority is an good idea, and there is a user voice here to suggest the feature, you can go and vote it up to achieve it in future.
Currently as a workaround, you can set the demands in build definitions to force building with the specific agents.
To do that, you can reference below articles:
How to send TFS build to a specific agent or server
Build vNext, distributing load to different agents
For on-prem TFS 2017 when I try to update all agents in the agent pools, the update does not happen. I see the same old agent version.
Build servers typically do not have internet connectivity.
Is internet connectivity a pre-requisite for updating on prem build agents?
I had to download the new agent for a machine where I have internet and then copied the files over to a new folder in the build machine and reconfigured the agent from this new folder. After this is done I had 2 agent services - 1 pointing to older folder and 1 pointing to new folder. The service pointing to old folder was started and the new service was in stopped state. Stopped the old service and started the new service.
Is the process different for updating agent version for on-prem TFS?
Even if you have Internet connection, the update may not work.
According to Daniel Steiner there are 2 kinds of agents:
Windows specific agents (version 1.x)
cross platform agents (version 2.x)
In TFS 2017 the Windows specific agents (version 1.x) are deprecated. Thus they won't be updated from the agent queues admin area. So you have to download the agent from tfs (or github) and install it yourself. After initial installation/configuration the agent updates via tfs should work again. It would have been cool if they automated that process or at least said what to do in tfs.
Unfortunately the official docu does not make the whole issue clear enough.
Yes you need internet connectivity for updating on prem build agents.
Each agent automatically updates itself when it runs a task that
requires a newer version of the agent. But if you want to manually
update some agents, right-click the pool, and then click Update all
agents.
All build agents within the selected pool will go offline temporarily and then come back online as soon as they are updated.
Which you have done is manually adding a newly version agent, not updating the agent. There are just two agents in your build server,so you had two agent services.
More details about update agent in on-premise TFS server, you could refer below tutorials:
Updating Your Team Foundation Build Agents
Upgrading TFS 2015 Build Agent
In TFS 2015 Update 2, I have configured seven release agents in one pool, separated into a set of logical environments using capabilities.
I also have a release configured with three environments defined to use the queue corresponding to this pool and demands specified to filter to the appropriate servers for each environment (1-Test, 2-QA, 4-Prod).
My problem is that TFS is only releasing to the first agent created that meets the demands. If I remove all demands in an environment I would assume it would release to every agent in the pool yet TFS still releases to only the first agent in the pool. If I disable that first agent, it will release to the next; but still to only one agent.
What am I missing?
I think you're misunderstanding what agents are for. The agent merely acts as an invocation mechanism for your deployment activities. You don't need one agent per environment or per server.
For example, if you need to run a PowerShell script on a machine, you use the "PowerShell on Target Machine" deployment activity. The agent will then use WinRM to tell the target machine what scripts to run. That agent can run PowerShell scripts against any machine.
Why would you want the release or build to select a different agent every time? I had always seen with TFS that the probability of a build running on the agent, where the last successful build for a specific build definition ran, is very high.
The only reason I think a build/release should run on a different agent every time is if the number of builds running at a same time requiring the same capabilities is more than one.
If you would like to test each of the agents then try disabling one agent at a time and run the build/release.