Trying to set up build server after upgrading to TFS 2015.
The way I envision is:
Single Agent Pool, that will have 3 queues:
1. Nightly builds
2. CI builds
3. Gated/validation builds.
Each of them will have some agents, the goal is to have some control, to make sure nightly builds wouldn't consume all agent, so gated queue will always have some available agent.
The problem I have now is when I try to add new queue, the option "Use existing pool" is disabled, I can only add queue with creating new agent pool.
It doesn't work the way you want it to work.
One agent can be a member of one and exactly one agent pool. The agent pool exists at the server level, not the Team Project Collection level.
One agent queue is tied to one and exactly one agent pool. However, agent pools can be referenced by different agent queues across Team Project Collection boundaries.
So, the upshot of this is that you can share your agent pools across multiple team project collections.
In VSTS, the distinction exists but is less relevant -- you can't have multiple Team Project Collections, so an agent pool and an agent queue are more or less equivalent, you just have to manage both of them.
You can use custom Capabilities (on your agents) and Demands (on your build definitions) to ensure that particular agents are always reserved for particular build scenarios.
Of course, task-based builds don't support gated checkin for TFVC yet, so your concern about gated agents always being available is moot, at least for now.
Now that all of that is out of the way, the answer to your question is simple:
Q: I'm trying to create a queue that uses an existing pool, but the
controls are grayed out. Why?
A: On the Create Queue dialog box, you can't use an existing pool if it
is already referenced by another queue. Each pool can be referenced by
only one queue. If you delete the existing queue, you can then use the
pool.
Ref: https://msdn.microsoft.com/en-us/Library/vs/alm/Build/agents/admin
Related
I am wondering if there is a way in TFS to prohibit new builds from queuing if there are no agents online to run it.
I am asking this because we have a build job that kicks off every 15 minutes. Occasionally our test agents will become disconnected and unavailable. This causes a bunch of build jobs to stack up in the Queue.
Is there a way to tell an automated TFS build definition to not start if all agents are offline? I know we can limit the amount of time one can run before it stops but that only works once its started. If it cant kick off because no agents are available, then this guard will not work and the queue gets backed up.
Sorry, there is no way to do this. When a job add to the queue, the build agent downloads a listener OAuth token and uses it to listen to the job queue.
Periodically, the agent checks to see if a new job request has been posted for it in the job queue in Azure Pipelines/TFS. When a job is available, the agent downloads the job as well as a job-specific OAuth token. This token is generated by Azure Pipelines/TFS for the scoped identity specified in the pipeline. That token is short lived and is used by the agent to access resources (e.g., source code) or modify resources (e.g., upload test results) on Azure Pipelines or TFS within that job.
More details please take a look at agent communication with Azure Pipelines
We have a pool and its ID is 1, added agent to it, gives the queue id as 3. We have two different projects in same collection. While creating the build definition for both of them when try to fill agent queue we get the same queue selected however, looking at corresponding build definition Json we see a different queue Id's for the same queue. Is that a bug ???
No, it's not a bug.
An agent pool is an independent entity scoped at the server/account level.
An agent queue is a "pointer" to an agent pool, to limit access to agent pools to only projects that require them. Each agent queue has a different ID, because they are different entities, regardless of what agent pool they point to.
On Team Foundation (TFS2017) which is the maximum number of build agents that you can have connected to your TFS instance?
There is not any official document statement the limitation of build agent numbers with TFS for now. Also didn't get any related prompt info such as: build agents have reached the maximum.
For multiple machines, you could configure as much as you require, there is no evidently limitation.
For a single machine, it depends on the hardware. If your agent server is virtual, then it is already slower as compared to the physical, you also need to allocate sufficient RAM for it.
Can I install multiple private agents on the same machine?
Yes. This approach can work well for agents that run jobs that don't
consume a lot of shared resources.
You might find that in other cases you don't gain much efficiency
by running multiple agents on the same machine. For example, it might
not be worthwhile for agents that run builds that consume a lot of
disk and I/O resources.
You might also run into problems if concurrent build processes are
using the same singleton tool deployment, such as NPM packages. For
example, one build might update a dependency while another build is in
the middle of using it, which could cause unreliable results and
errors.
Source Link
It depends on how many cores agent server has. One Agent will take up one core.
We're seeing a problem with Jenkins and the scheduling of builds. Specifically, we trigger Jenkins to build a pipeline of work with every push to every branch of our git repo. On its own, the whole pipeline can take from 10 to 20 minutes to build. This can cause a problem if multiple pushes to a branch happened faster than the builds are completing. Multiplied by the twenty or thirty branches that are in development.
So, I'd like to be able to automatically deprioritise any scheduled builds on Jenkins if they are triggered on a Git commit sha that is no longer the tip of its branch. This is just one example of a factor that might indicate a desired priority. Others would be that branches with open pull requests should have higher priority than those without; or manual input in order to prioritise a PR or branch that needs feedback immediately.
Is there anyway to programmatically interact with the Queue of jobs on Jenkins and reorder it?
There is the Priority Sorter Plugin, but as far as I know this assigns each build a static priority. I would like to dynamically reprioritise items in the queue based on external info (e.g. from git).
I've found reference to two other plugins whose names indicate that they might do what I want, but I can't find any meaningful documentation on them. The former doesn't provide the options it claims to, and the latter doesn't even exist in the plugins repository. Neither seems to be maintained.
My alternatives seem to be
write my own implementation of hudson.model.Queue, which seems like overkill
maintain a separate queueing service that triggers individual jobs on Jenkins, in which case what is Jenkins even for?
Am I missing something obvious? I can't be the only person who wants more fine-grained control of Jenkins build ordering.
When I create a build definition I'm asked for one or the other. What is the main difference? Is this a dummy question? I'm new on configuring build templates. I can create them, but I want to understand them also!
The Hosted queue is Microsoft's queue. It has a certain set of capabilities available, and you can't change that.
The "Default" queue is your on-premise build agents, assuming you set them up. You can create multiple queues, as well.