Related with the last TFS version:
Can a build agent run simultaneously n number of builds?
Sometimes my builds takes too long I wanted to know if there's some other ways plus making a new agent.
Thanks!!!
An agent can only run one build at a time. If you want multiple builds in parallel you need multiple agents.
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 was hoping someone could help with ideas in Jenkins for sharing a build increment across multibranch pipelines on multiple build machines. Looking through similar questions, I didn't see anything better than timestamp instead of build number but it's not quite what we were looking for.
I am using Jenkinsfiles to define multiple pipelines, then 'multibranch' to instantiate them across all branches. Currently these just call shared freestyle jobs to implement the stages. Every pipeline invokes the same job to do a build, across a pool of build machines, so we can just use that build number to increment the version. For example I have v1.2 being worked on by several branches, each having a CI, Nightly, and Release pipelines. They all invoke the same build sub-job so you might have CI/BranchA run sub-job #503 on buildVM1 so will have version string 1.2.503, then Nightly/BranchB will run sub-job #504 on buildVM2 so will have version string 1.2.504. This works great as long as I am invoking the same build sub-job.
The next step is to implement the builds as part of the Jenkinsfile pipeline, but then I lose my convenient build increment. How can I define a shared build increment for this component across all branches defining the same major.minor version?
Timestamp is a bit unwieldy since the multiple branches/teams/build machines means I need to go to seconds. Do I really need versions like 1.2.20180118165007? There's got to be a better way.
How else can I manage this?
In TeamCity there is the possibility to limit the concurrent builds per build definition. This means you can build multiple definitions at the same time, but if 1 definition is queued multiple times, it wil be executed 1 by 1.
Limit the number of simultaneously running builds
Specify the number of builds of the same configuration that can run simultaneously on all agents. This option helps avoid the situation, when all of the agents are busy with the builds of a single project. Enter 0 to allow an unlimited number of builds to run simultaneously.
Is there a way of doing this in TFS 2015?
You can use the agent user capability to direct a specific build definition to a specific build agent resulting in one running build of that build definition
I have a MsBuild process that start as part of build using TFS Build Services 2013. I need to pass a few parameters to this process (for example the build number). I've done this previously by modifying the build template and added these parameters to the list of parameters sent into MSBuild, something that has worked fine.
I did however found that TFS Build Services writes a number of environment variables for run (build number being one of them) and as I easily can change my MSBuild script I'd rather just use these directly variables instead of modifying the build template.
My question is however how this will work when I have several build agents? Won't they write over each others values in the environment variables? Can I be 100% certain in my MSBuild script that I didn't get the build number of the next build that might have started in parallel?
Each TFS build is done using a specific build number. If you have multiple agents working on a 'parallel' build, they will all use the same build number. Each build agent will be running in their own specific environment and will not have any issue if other agents are running in parallel - the build number for one agent will not 'clobber' another during a build.
Consider TFS 2010's ability for a Build Controller to have 1+ build agents. Since builds are a subjective topic to the team/environment, consider an environment where builds are performed on commit/check-in. Each Project Collection will have 10+ Team Projects, but perhaps only 1 or 2 are being committed to in a day.
When should a TFS administrator consider creating a new build agent?
Do multiple agents run in parallel?
When a single agent is defined to a Build Controller, does it run serially?
MSDN states: "if you set up your agents to have specialized capabilities..." . What does this mean? A technology/platform differentiator? How can you setup your agents to have specialized capabilities?
How can 'tagging' build agents be used effectively in an environment where builds are (typically) performed on each check-in.
You use multiple build agents to support multiple build machines (I work currently with a build farm with 3 build machines - and thus 3 build agents - to distribute the load).
You also might want to have multiple build agents to be able to run builds in parallel. This is a nice feature to share resources, but a requirement when you start working with Test/Lab Management features.
With the capabilities: for example you can setup a build agent with version 1 of a 3rd party component, and a second build agent with version 2. With tagging you can specify in the build definition which build agent it will choose from out of the pool of build agents.
We use 2 build agents on the same machine at work, since we only have one build machine.
The first one handles our CI builds, and is tag with CI. The build definition for the CI build is set up to only use agents that have the CI tag.
The second one is for manually queued builds, mostly for the release branch builds.
I specialized the CI build agent, because it was not uncommon when we were preparing a new build for QA to have several developers check into the development branch, which would slowing down being able to release the build to QA.
One of our builds takes 9 minutes. Its nice that you don't have to be in the Queue behind it if you happen to deploy at the wrong time.