Using TFS Build Server as contionuous integration system, I would like to know if it is possible to set some build definitions as High Priotity Builds.
You can't do this directly, but there is an approach I've used to accomplish a similar thing. If you setup multiple build agents (on one build server, or multiple servers), you can use Build Agent Tags.
Lets say you have 4 build agents. What you can do is tag 3 of them with a tag like "LowPriority", and leave the 4th agent with no tags.
Then in your low priority build definitions tell them to only run on build agents with the LowPriority tag, set the high priority build def's to run on any build agent.
This effectively reserves a build agent to be used only for high priority builds, which will allow them to "jump the queue".
Related
We use the multi-configuration according to the BuildConfiguration variable and run the release and debug in parallel with Clean:false in one of our builds.
In the agent queue, we have two agents that meet the requirements for this particular build definition.
The problem is that the agents can not be set on this build.
That's why you can not say for sure that debug will always be built on agent x and release on agent y.
If now once release on the agent x is built, then the files are around there and will not be deleted.
If this causes it to copy something over it when populating the drop, then "outdated" files will end up there.
One option would be the Clean:All, but we do not want to miss the incremental mode.
Is there a solution for this problem?
No, Your scenario is simply not supported. You CAN work around it by having one queue / set of tags to basically have a group of ONE agent, but that is it.
Otherwise you simply are out of scope. Tasks on agents are supposed to be standalone. CLean all = false is supposed to be purely a performance tuning (no need to compile things not changed etc.) NOT supposed to allow followup jobs to reference as state another job has left an agent in.
What I do in some scenarios like that is using my own file server as buffer. Given that my agents run locally and have a VERY high bandiwdth connection (200 gigabit per server), I can just move compiled results into a buffer folder and back with basically zero overhead (as in: zero feeled overhead). Particularly in multi agent jobs that really helps (downloading selenium tests 16 times for 16 agents - no, thanks).
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 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 am trying to dynamically apply priorities (from 1 to 5) to Jenkins jobs started via a URL containing the BuildPriority parameter.
In the Priority Sorter Config I selected
->Use additional rules when assigning a priority to a Job
and chose "Use Priority from Build Parameter" as Build Strategy.
I left Build Parameter Name = "BuildPriority".
Starting the Job via:
http://localhost:8080/job/myJobName/buildWithParameters?PARAM1=value1&PARAM2=value2&BuildPriority=1
doesn't apply the priority. I tried to add a string Parameter to the Job named "BuildPriority" which didn't work as well. What am I doing wrong?
Many thanks in advance,
marcus
Update:
I found this related Bug already tracked:
https://issues.jenkins-ci.org/browse/JENKINS-22294
Update 2:
For those searching for a solution I can offer a workaround:
Allow parallel builds for the corresponding job and reduce the number of processors/cores in Jenkins settings to 1. If this is not an option for you, as you want to use all cores, install Throttle Concurrent Builds Plug-in which allows you to "throttle" every Job on its own to as many cores as you want.
Throttling to 1 and allowing parallel builds got me the behaviour I expected.
The Priority Sorter Plugin (as of Plugin Version 3.6.0 with Jenkins 2.73.3) will be prevented from even "seeing" a queue for a single Job, unless the option Execute concurrent builds if necessary is checked.
Therefore: Allow parallel builds for the corresponding job and reduce the number of processors/cores in Jenkins settings to 1. If this is not an option for you, as you want to use all cores, install Throttle Concurrent Builds Plug-in which allows you to "throttle" every Job on its own to as many cores as you want. Throttling to 1 and allowing parallel builds got me the behaviour I expected.
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.