James, thanks for that! For some reason I never found that option! I agree the UI is far from consistent. There's some weird UI and feature set differences between build plans and deployment projects.

Martijn, I agree with you on the requirements, but you*_ can_* clone deployment plans. If you go to edit a deployment project, you can clone the whole thing from the drop down in the upper right corner, the one with the three dots. Clone project is right there between Edit project details and Delete project. No idea why this UI is so different to that for the Build projects, but it certainly does what you'd expect.

While the plugin workaround is useful... and I do consider it a workaround... I'm truly amazed about the huge, gaping hole in the feature set of deployment plans left by Atlassian that should be fairly easy to fix.

Specifically two items stick out:

• Not being able to clone deployment plans
• Not being able to set requirements on a deployment plan

The cloning feature already exists for build plans and works nicely. It should not be difficult to do the same for deployment plans. Slightly different screen and slightly different set of DB fields to clone.

The requirements feature not being there really boggles the mind for me. We have this annoying "agents" button in the environment config screen, but not a very much needed "requirements" button. Apparently the feature isn't that hard to do since we have that plugin that does it, so why not have that button in the environment config screen??

While you're at it, please, please, please remove the "agents" button or at least allow us to turn it off. It has already caused havoc on our systems because a user decided to dedicate all of our agents to his deployment. I know we can revoke his permissions to edit the deployment plan, but I don't want to do that since the whole "dedicate agent" feature is not exactly properly explained, nor even very necessary.

Jules, if you're not using the Windows image at all, you can also disable it on image config page.

If you are looking for this feature - you can use the following plugin to add requirements to deployment environments.

https://marketplace.atlassian.com/plugins/com.atlassian.bamboo.plugin.requirementtask/server/overview

Please implement this. For some reason the Windows stock image is the default, where our deployment is Linux based.

Agree with those above. Having to tie agents to deployment projects means we have no choice but to segregate a group of agents for this purpose - taking them out of consideration for other activities.

Agree with @richard.beers620876970. Please re-evaluate the priority of this ticket.

(@spittet are the PM for Bamboo Cloud?)

For cloud bamboo, this is IMHO a important feature to have.

This is my use case:

I now work with dedicated images. That works. For both build plans and deploy plans.

I would like to be able to use capability on images, and requirements on plans. This works fine with build plans.

If I use it on my build plan, it seems logical to me I also do the same with deploy plans. This seems not possible.

This forces me to use a dedicated image for the deploy plan, however this now prevents me from using this same image by the build plan through capabilities/requirements mapping.

Therefore I now also need to use dedicate image to force the build plan to use it. This is much less flexible then using requirement/capabilities.

If I edit a deploy plan I can select an agent/image in "other environment settings", if I do so, the text displays: "Dedicate specific agents or image configurations to execute all deployments for this environment. If you do not assign an agent to this deployment, one will be chosen at run time according to standard requirement/capability mappings."

So please implement it, your text is already ready!

Thanks ! The incompatibility warning is now gone !

arjen.devet I've updated the plugin compatibility on marketplace; as far as I can tell version 1.5 works with latest Bamboo without issues.

I would love to see this feature implemented for deployment project as well.

(We are using Bamboo Cloud and therefore unable to use the plugin.)

@spittet Can we get an update on this ? The current plug-in version is not compatible with the current bamboo version 5.10 .

It does seem major to me since the plugin cannot work on Bamboo Cloud therefor there is no workaround.

@asanga s, I guess it's "minor" because it has a workaround. The plugin works quite OK for me.

I understand that you guys have a lot on your plate, but I fail to see how this is given a 'minor' priority. 158 votes does not seem minor to me.

Hi,

I just wanted to provide an update on this request. We are still unable to provide full support for the deployment requirements plugin. Please keep using the plugin referred to by Cintia and send us a pull requests if you need it to be updated.

I cannot provide a deadline but I do not expect the team to be able to look into full support before the end of 2015.

Thanks everyone for your feedback, please know that we read it and take it into account when prioritising our roadmap but due to other factors we are unable to put this development on top of the backlog.

Thanks,

Sten Pittet
Bamboo Product Manager

The plugin is now open sourced https://bitbucket.org/atlassian/bamboo-requirement-task/overview

Issue added here uninstall/reinstall does NOT work. https://bitbucket.org/atlassian/bamboo-requirement-task/issue/1/requirementtask15jar-does-not-load-on

Ugh, that doesn't look good. I couldn't reproduce with empty 5.8.1 nor with my newer instances.

One thing you can try: uninstall it and install it. It won't lose any tasks using it. Can we move this talk to https://bitbucket.org/atlassian/bamboo-requirement-task?

SO it seems that when I upgraded with this plugin in place, it continued to work despite show up as invalid, but when I disabled it, I can now no longer enable it. Any suggestions on how to get it working again? I find this in the log:

2015-05-14 12:30:32,746 ERROR [http-nio-7990-exec-1] hmardis @BF5Q5Xx750x144342x0 7g5ekk 10.60.1.12 "PUT /rest/plugins/1.0/com.atlassian.bamboo.plugin.requirementtask-key HTTP/1.1" c.a.plugin.osgi.factory.OsgiPlugin Detected an error (BundleException) enabling the plugin 'com.atlassian.bamboo.plugin.requirementtask' : Unresolved constraint in bundle com.atlassian.bamboo.plugin.requirementtask [103]: Unable to resolve 103.0: missing requirement [103.0] package; (package=com.atlassian.bamboo.v2.build.agent.capability).  This error usually occurs when your plugin imports a package from another bundle with a specific version constraint and either the bundle providing that package doesn't meet those version constraints, or there is no bundle available that provides the specified package. For more details on how to fix this, see https://developer.atlassian.com/x/mQAN
2015-05-14 12:30:32,747 WARN  [http-nio-7990-exec-1] hmardis @BF5Q5Xx750x144342x0 7g5ekk 10.60.1.12 "PUT /rest/plugins/1.0/com.atlassian.bamboo.plugin.requirementtask-key HTTP/1.1" c.a.plugin.impl.AbstractPlugin Unable to enable plugin 'com.atlassian.bamboo.plugin.requirementtask'
2015-05-14 12:30:32,772 WARN  [http-nio-7990-exec-1] hmardis @BF5Q5Xx750x144342x0 7g5ekk 10.60.1.12 "PUT /rest/plugins/1.0/com.atlassian.bamboo.plugin.requirementtask-key HTTP/1.1" c.a.plugin.impl.AbstractPlugin Because of this exception
com.atlassian.plugin.osgi.container.OsgiContainerException: Cannot start plugin: com.atlassian.bamboo.plugin.requirementtask
	at com.atlassian.plugin.osgi.factory.OsgiPlugin.enableInternal(OsgiPlugin.java:479) ~[atlassian-plugins-osgi-3.2.15.jar:na]
	at com.atlassian.plugin.impl.AbstractPlugin.enable(AbstractPlugin.java:310) ~[atlassian-plugins-core-3.2.15.jar:na]
	at com.atlassian.plugin.manager.PluginEnabler.actualEnable(PluginEnabler.java:136) [atlassian-plugins-core-3.2.15.jar:na] ... 

Hey hmardis1,

I do understand that the listing in marketplace says it's not compatible, but I can tell you we've been using it and we haven't had any problem with 5.8.1 or even our newer internal releases.
Can you please install it in a 5.8.1 instance and let me know if you run into any trouble?

The plugin is not yet open source, so I cannot give the source right now.

The non-supported plugin noted above is no longer valid on bamboo 5.8.1. When I tested my upgrade we looked at the few deployment uses we have and THOUGHT that there was a new task in 5.8.1 that provided this functionality. Apparently our originally assessment of that was incorrect. Can I get the source for the unsupported deployment requirements task so I can rebuild/test/use with bamboo 5.8.1?? Or can a new version be built that continues to work with the latest bamboo? We are now having to figure out a workaround for this. Thanks,

Hi,

I'd like to provide a quick update on this issue.

As ccalvo mentioned it we have an unsupported plugin for the deployment requirements. We've recently reviewed our list of plugins published as Atlassian Labs and the Deployment Requirements plugin is a strong candidate for official support.

I cannot give you an exact deadline but we're targeting mid-2015.

Thanks,

Sten Pittet
Bamboo Product Manager

Thanks for the info.

ken.sykora and david.weisgerber, there's already a (non-supported) plugin for that, https://marketplace.atlassian.com/plugins/com.atlassian.bamboo.plugin.requirementtask

david.weisgerber We were able to work around this issue by creating a custom task that has a requirement on MSBuild.exe. A basic custom task like that is fairly straightforward to make with the Atlassian SDK. I'd recommend going that route, or I can send you the one that we created if you like.

This is partially a showstopper for us. Consider having windows and linux machines and a deployment needs to execute certain programs / scripts... Now I would need that all my build agents would be able to run this!

We released our internal plugin on marketplace. It should be working for Bamboo 5.1+

It provides a new task to add a requirement (the task doesn't do anything else). So, in your deployments, just add as many of those tasks as you need, one per requirement.

It's not a perfect solution, but it's a nice workaround for the moment. We will be looking on how to address this feature request better.

one more scenario to emphasize the importance of this : Im using ssh command as part of my deployment plan, and because I have both windows and linux all the deployment concept is not useful for me .. and no i cannot add ssh client on my windows machine

Yes, I can't believe how broken this is. Considering how expensive remote agent licenses are, it is totally wrong to dedicate the agent to the job.

I'm not sure if Atlassian recognizes this need. In case you don't, consider the following scenario. We have two environments to which we deploy – QA and Prod – and multiple Bamboo Agents. For safety's sake, we don't want every Agent to be able to deploy to Prod, so we set up one of the Agents to run under a privileged user account. For normal activities (building, deploying to QA) we want any available Agent to handle the execution as to distribute the load. But for Prod deployments, we need to route the deploy plan execution to the one Agent.

The implementation of the dedicate model is simply broken. Several times we've starved all but a few jobs from running because people would want to dedicate their job to an agent, not understand they're dedicating the agent to that job, not that job to the agent.

Either flip what it means to dedicate ("pinning" a job, vs dedicating an agent) or allow us to use Requirements to intelligently route jobs to agents.

I agree that the desired functionality would be to allow the requirements to be set against deployment environments.

Aidan's workaround has worked for us. The trick is to define an executable that has a unique name among your remote agents, then call that executable as a task in the deployment plan. We use /bin/echo on our linux machines, and c:\windows\system32\whoami.exe on our windows boxes. You don't actually need a unique executable on the disk, it only has to be configured to have a unique name on each agent.

I am in need of this feature, and i might be wrong but it seems to me that some type of plugin exist that Atlassian uses internally that would work until it was baked into a version.

http://blogs.atlassian.com/2013/11/fisheye-continuous-delivery-with-bamboo-deployments/

In the screenshots, under the Update Tasks, there is an
"Add Requirement" task

any chance that it could be released under the "Atlassian Labs" bitbucket?

We need this feature to control what remote agent to use, by using requirements as it done for builds, as we have a few remote agent all on different network. Using the agent as deployment agent means it can't build the artifacts, which means two remote agents. Having a requirements to control witch agent to use would solve our problem.

An alternative to make a specific remote agent available for build and deployment, would be to add a simple custom executable capability (eg: have a custom script on the remote agent that no other remote agents have) for the remote agent instead of dedicating the remote agent to a deployment plan. In the deployment plan add an executable task that calls the new custom capability. I think it'll would be cleaner to be able to define requirements for the deployment environment or remove the limitation describe in BAM-13631

Hey, this would be great for us. We are using ansible to configure machines, but have to use custom capabilities so that the build runs on the correct agent (since we are using a corporate build server, and only have control over 3 remote agents). We couldn't see a way to use custom variables so our workaround in the meantime was to define a separate non-custom capability. We modified our Maven and Java executable capabilities so that they had different names (long insane ones so no one else is likely to use them on their agents accidentally), and then we added a minimal pom.xml to our bamboo build artifact. Finally in the deployment plan we added a maven task which uses this executable and added a no-op goal (we chose pre-clean), this enforces the use of our specific agents for this task. I hope this workaround helps someone else.