As per TFS documentation (Documentation), when the "Batch changes" option is selected, the maximum number of concurrent builds can also be specified, but I can not find any documentation on how to limit the maximum number of concurrent builds. Any help, please?
First just as the doc said, the batch changes is used for reducing the number of builds you are running.
If you select this option, when a build is running, the system waits
until the build is completed and then queues another build of all
changes that have not yet been built.
However you can't run multiple solution builds in parallel in TFS 2015, it's only able to run multiple configurations and platforms in parallel. Some related topic:
Parallel build in TFS 2015?
TFS 2015 v.Next build: Parallel solution builds?
So the concurrent builds should be running builds on multiple build agents the same time. You can't run concurrent builds on a single agent. It looks like a lack of content, I will submit this through internal channels, once updated will let you know. You could also submit a feedback on MS connect page or GITHub Issues page. Through this you may get a faster response.
Related
I need to incorporate a task in my build to perform a Fortify Scan. My issue is I have one agent and scans take 1 to 2 hours, which ties up the one agent. I then tried to create a build that would start a scan of are TFS/SCM only to kill it after it ran for over 8 hours. Is there a way to create a task that only runs the changes for that day?
Since you are using Team Foundation Server 2017. As part of your build and release process you could execute Micro Focus Fortify security scans and upload the results to the Fortify SSC server.
It's also able to make the build/release fail whenever the scanner detects new critical or high findings in the code. We could use the Micro Focus Fortify plugin for TFS to configure the scan step and upload to SSC: (Fortify TFS plugin). Just add a PowerShell task afterward to attempt to query for findings and fail the build if needed.
Is there a way to create a task that only runs the changes for that day? There is also a concept called Scheduled Trigger which select the days and times when you want to run the build. Just make sure to check "Only schedule builds if the source and pipeline has changed" All support triggers are list here --Build pipeline triggers, please kindly take a look at it.
I have created a vNext build definition in TFS 2018. I'm able to queue this
build definition many times and they were processed parallel.
This behaviour is not acceptable. If they are processed in order, I can live with it.
Does anyone know which setting I have to setup in the definition?
I'm running a tfs in following environment:
TFS 2018.2 On-Premise
4 Build-Agents with different capabilities
1 Build-Definition which fulfills the capabilities of all agents
It is planned, to have more build definitions. Today, we have only one because we are migrating our xaml-builds to vNext.
On the Triggers tab, check the "Batch Changes While Build is in Progress" option and set the number of concurrent builds to 1.
However, I would strongly recommend fixing whatever prevents your builds from running in parallel. Builds should ideally be stateless and have no impact on one another.
You can also set a custom Demand/Capability pair such that only one of your agents satisfies your build definition's requirements.
I am running into problems getting my build servers to run releases in parallel.
I just recently created my second build and test server. Both servers correctly run builds in parallel. And each of my builds triggers a release upon successful completion. However, only one server at a time will run a release.
I have verified that both servers are configured correctly because if I take down one server the other one starts running the releases correctly. However, when both are stood up together only one of them will run releases.
Is there a setting in TFS that does not allow multiple separate release definitions to run in parallel on different machines?
A TFS concurrent pipeline gives you the ability to run a single release at a time in a team project collection.
You can keep hundreds or even thousands of release definitions in your collection. But, to run more than one release at a time, you need additional concurrent pipelines.
One free concurrent pipeline is included with every collection in a
Team Foundation server. Every Visual Studio Enterprise subscriber
in a Team Foundation server contributes one additional concurrent
pipeline. You can buy additional private pipelines from the Visual
Studio Marketplace.
Purchase additional concurrent pipelines
If you need to run more concurrent releases, you can buy additional private pipelines from the Visual Studio marketplace. Since there is no way to directly purchase concurrent pipelines from Marketplace for a TFS instance at present, you must first buy concurrent pipelines for a VSTS account. After you buy the private pipelines for a VSTS account, you enter the number of purchased concurrent pipelines manually on the resource limits page described below.
http://{your_server}:8080/tfs/DefaultCollection/_admin/_buildQueue?_a=resourceLimits
Note: above is for TFS2017/2018.
If you are using TFS2015, take a look at this question: Do I need concurrent pipelines to use release management in versions before TFS 2017?
More details suggest you go through the official link in MSDN: Concurrent release pipelines in Team Foundation Server
The system seems to still be based on the honor code.
Through the link PatrickLu-MSFT gave I was able to change the number to anything I wanted, even though I did not actually purchase any additional licenses.
After resetting the additional licenses back to zero, I also found this link:
http://{your_server}:8080/tfs/_admin/_licenses
Again, it seemed to be based on the honor code here as well because I was able to add users with subscriptions to less than Enterprise to the VS Enterprise group.
However, when all my exploring was done, I was able to use that final link to enter the people who do have Enterprise subscriptions and that changed my overall license count so I was able to run releases in parallel.
I have 10 build agents configured in two servers under one agent pool. Whenever the first four agents are used, the build requested is in the queue on the first four agents, but there are another six agents which are available and the builds are not queued to those agents.
It's been almost six months and agent 10 has not even once handled a build. Other agents from 5 to 10 are hardly used. Why is there this phenomenon? How can we handle this by using all the agents fairly?
TFS will auto select the available build agent in the pool when running the build. It's more like a conditional random choice. It's not able to prioritize the build agent for now. There has also been a related uservoice as below:
TFS 2015 build vNext agent prioritization
As a workaround you could specify a build agent in vNext build.
You can add a User Capability to that specific build agent. Then in the build definition you just need put in that capability as a demand (General tab).
It seems like the builds are queued on the 'oldest' agents first. So if agent 10 is the last agent you created, it will only be used if the first 9 are in use, assuming they all have the same capabilities.
It does not appear to be a random selection of agents, but based on the order of creation of agents. Ironically that means that if you add a new powerful build server, those agents will be at the bottom of the queue.
The user voice suggestion in PatrickLu-MSFT's answer is to allow the agent to be prioritized.
The workaround at this moment seems to be to remove all (or some) agents and re-create them in the order you want them to be used. Which still means the last agent will be used less, but at least you can influence the distribution of the agents a bit.
We are running into this issue as well. We have six build servers with three agents each and builds are not distributed fairly. I also do not want to assign an agent per definition, but I guess we are going to have to puzzle with it.
I have a TFS 2010 build service installed with three agents: Database, Production, and Release with mutually exclusive sets of builds running on each.
When builds are queued, unfortunately, they appear to get queued in groups of three regardless of which agent they're ready to go to. This means that we lose the parallelism I was hoping for if more than three builds from a single agent are run at once as they will take up the entire queue.
Is there a way to make sure that builds are queued once their own agent becomes free so that we can have as many parallel builds as possible?
Using the TFS 2010 default build defintion you cannot select an build agent but only a build controller unless you have customized it. Ideally you should have a single build controller, which has multiple build agents beneath it. Within the build definition you would only be selecting controller name and the build controller pushes the build to the agent which is free at that point. You can also use TAGS to make sure that the build runs on only a particular build agent.