Previously, you could assign Plans to Queues. This gave you the ability to control exactly what Plans would run on a given Queue.
Now, each Plan has requirements, that may be met by any number of Agents. You cannot forbid Plans from running on an Agent: if the Agent meets the requirements of a Plan, it will greedy build any of those Plans.
Desired It would be good to be able to configure an Agent to only run a given set of Plans. For example, you might want have an Agent that has the same capabilities as any other Agent, but is always available to do a particular build as soon as a commit occurs to a given codebase – it is not acceptable for that build to wait on the next available matching Agent.
Current workaround Create n-squared properties on each Plan and Agent, excluding all-but-one Plan from running on a given Agent.
Proposal: Agent Prerequisites
Currently Plans state requirements that are satisfied by Agents.
We could add a reverse of that relationship:
- Agents can state Prerequisites that are satisfied by Plans
For example, an Agent could have a Prerequisite "clover-optimized-build-only". And only Plans that satisfy that Prerequisite will run on that agent.
(NB: this should apply to all agent types, remote, local, etc.)
- blocks
-
BAM-11095 Provide functionality to choose an agent to run a build
- Closed
- duplicates
-
- Closed
- is duplicated by
-
- Closed
-
- Closed
-
- Closed
-
- Closed
-
- Closed
-
- Closed
- is related to
-
- Closed
-
- Closed
- relates to
-
- Closed
-
- Closed
-
- Closed
-
- Gathering Interest
- supersedes
-
- Closed
- mentioned in
-
Page Loading...
-
-
-
-
-
-
-
- was cloned as
-
[BAM-3491] Limit an Agent to given Plans
| Workflow | Original: JAC Suggestion Workflow [ 3015535 ] | New: JAC Suggestion Workflow 3 [ 3611494 ] |
| Status | Original: RESOLVED [ 5 ] | New: Closed [ 6 ] |
| Workflow | Original: Confluence Workflow - Public Facing v4 [ 2703404 ] | New: JAC Suggestion Workflow [ 3015535 ] |
| Backlog Order (Obsolete) | Original: 8640000000 | |
| Issue Type | Original: Improvement [ 4 ] | New: Suggestion [ 10000 ] |
| Workflow | Original: Bamboo Workflow 2016 v1 [ 1410789 ] | New: Confluence Workflow - Public Facing v4 [ 2703404 ] |
paul981668836 it is admittedly less useful now with dedications, but my free Group Agent plugin was created to solve just the challenge you mentioned.
Agents can be denoted as a reserved agent via a new Group Agent capability. Only plans that specific that agent by name are allowed to use it. (in our company only authorized admins can manage that aspect of build configuration ) Deployments can optionally inherit the rules specified by the build plan, or allow any deployments.
https://marketplace.atlassian.com/plugins/com.edwardawebb.bamboo-group-agent/server/overview
Hi @Bill Cernansky, that would be fine if you could switch off / disable the standard capabilities for an agent. As far as I can see there is no means of stopping somebody creating a deployment plan with a script task (rm -rf *) and running that on any agent.
Deleted Account (Inactive)
added a comment - I feel like this was a good addition, but frankly, controlling things like this with custom capabilities is super easy. We have 1000+ plans on many many agents, and it all works seamlessly and with little effort to set up.
Deleted Account (Inactive)
added a comment - I feel like this was a good addition, but frankly, controlling things like this with custom capabilities is super easy. We have 1000+ plans on many many agents, and it all works seamlessly and with little effort to set up. Referring back to the comment made by Adam Myatt on this ticket on 19/Sep/2011
"When large companies have multiple subdivisions or many teams, sometimes those teams perform work that is sensitive in nature and they do not (and in some cases cannot) have people from another team or subdivision running their builds on their agent."
Being able to assign a deployment plan to run on any agent without enforcing any constraints is really bad news.
@BASM Ltd,
Ah, now I see. Yes, it is a security problem. And I know, for as a Bamboo admin, I have used that capability to determine login information for an agent machine while the person who controlled it was on vacation. Anyone could do it. But (and this is nothing more than inconvenience) a non-admin would have to know which custom capabilities belonged to that particular agent.