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.
Related
I have many different jobs. Each job requires exclusive access to a physical device during its execution. There are five such identical devices, i.e. each job can use any of the five devices for its execution.
I'd like to be able to trigger 20 jobs and then want Jenkins to provision five agents and execute 5 jobs in parallel until the queue is emptied.
I've setup 5 dynamic agent templates. Each template having a different IP of a physical device as an environment variable and each template being limited to an Instance Capacity of 1. That should take care of the exclusive access.
First I have given each template the same label: 'my5devices' and set the jobs to use this label:
agent {label 'my5devices'}
yet Jenkins only ever provisioned one agent. In the queued jobs I could see, they were all waiting for this single dynamic agent to have a free executor.
I was observing the same, when given each template a different label and changing the job:
agent { label 'device1 || device2 || device3 || device4 || device5' }
It seems Jenkins never provisions more than one agent and therefore only ever runs one job after the other.
I have in Jenkins a set of jobs A1, A2, ... that can be executed concurrently, as well as a job B that must never be executed concurrently with any job Ai. All these jobs run on the same node (the jobs Ai use a pool of executors that, for reasons that can't be helped, occasionally have to be shepherded by job B). Can I enforce this in Jenkins?
The concept is similar to that of a shared mutex; the jobs Ai require shared-level access to the pool, while the job B requires exclusive-level access.
I'm looking at the Throttle Concurrent Builds plugin, but it appears from the options that it provides that it only has one level of access. I could make B never be concurrent with any Ai, but only by making all Ai mutually exclusive as well.
Is there a way to achieve shared-mutex-like behavior, either with this plugin or otherwise?
There's the Block queued job plugin:
Plugin for blocking/unblocking job in queue by some conditions configured in this job.
There's the Build Blocker Plugin:
This plugin keeps the actual job in the queue if at least one name of currently running jobs is matching with one of the given regular expressions.
Is it possible to block a certain jenkins job while another one is running as some sort of condition?
I would like job "A" to be disabled while job "B" is running, and once job "B" is done, then job "A" should be available again.
I have read that it is possible to block upstream jobs when the jobs are part of a flow and the flow is running, but I would like to know if it s possible for 2 completely independent jobs.
Use this Build Blocker Jenkins Plugin.
You can block A in job B's config. As long as 'A' is running, 'B' would not run.
You can block Both A & B in B's config, thus B would run only no other As or Bs are running.
Additionally, You can block B in A's config, they will block each other.
*job names are case sensitivity
You can use the Throttle Concurrent Builds Plugin to do this.
You're going to want to:
create a category for the two jobs in the Jenkins global
configuration.
In each build check the Throttle Concurrent Builds
option.
Choose Throttle this project as part of one or more
categories.
Set Maximum Total Concurrent Builds (and Maximum
Concurrent Builds per Node if applicable) to 1
Check the category box to mark the job as part of the category.
This will limit either job from running while the other one runs, so if Job A is running then B won't start, and if Job B is running than A won't start.
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
Is it possible to limit the number of instances of a single build configuration in the queue?
When a build is triggered I would like it to be added to the queue but if there are more than x instances of that build on the queue already then the oldest instance of the build in the queue is removed as well as the new instance being added.
Is there a plugin that does this?
Haven't used this plugin personally, but give it a try. I think it throttles the maximum no. of jobs instances in a given node or globally.
https://wiki.jenkins-ci.org/display/JENKINS/Throttle+Concurrent+Builds+Plugin