rajinel.prasad@optiver.com.au Unfortunately this fix does not work for Cloud instances. Any other suggestions in this case?

@Jeremy Frederick
This has been fixed using plugin: 'Requirement for Deployments' https://marketplace.atlassian.com/plugins/com.atlassian.bamboo.plugin.requirementtask

+1 on this. Instead of having to add a custom capability to an agent in order to force it to use that agent, it would be great to add a similar functionality as dedicated agent, but allowing that agent to still be used by other builds.

James,
The issue relates to deploys, builds are OK with determining which servers they are suitable for. However, it is not possible to ensure that an agent running on Linux only picks up the Linux deploys and that an agent on windows only picks up the windows deploys.
Obviously if a deploy for a Linux box has a Linux specific SSH piece in it, then when arbitrarily picked up by the Windows agent, it just isn't going to work.
There is no way of ensuring that a deploy only works with an agent that has the correct capabilities, unless you use the (fairly useless) feature of dedicating an agent to a deploy.
The requirement is to provide the same capability matching for deploys as occurs with builds.
Hopefully I have all that right and plain enough.
Cheers,
David

roy.lyons@cmegroup.com the SSH task doesn't work on Windows? That sounds rather serious. Have you a support case or issue I could read about this problem?

Hi there,

My sincere apologies for the radio silence on this ticket. This only came to my attention today and I'm not sure how it slipped through the cracks.

Let me know if I have the problem straight and what you guys believe the right solution is:

1. Dedicate agent lists agents that do not have the capabilities to run the deployment. We should be indicating for all agents dedicated to the environment if it has the right capabilities or not.
2. Task screen shows "available agents" that are not the assigned agents or agents that have the capabilities to run the deployment. The information is plain wrong and needs to be fixed.

Ill move this over to our internal backlog now and prioritise a fix.

Thanks,
James

I am sure someone from Atlassian must be reading these, but please, please, at least indicate some kind of acknowledgement so we aren't left feeling as though we are totally wasting our time? I note is assigned, but I would expect assignee to answer question comments in some way.
If it helps for Chris and Roy, we have had to develop a blocking process, such that when we have a deploy scheduled for our Windows box, it runs a 5 minutes before schedule that blocks the agent on the Linux box with a simple 10 minute build wait job. A real kludge, but gets us by for our simple needs. If you have more agents or more variable deploys, then may not work for you.

As a member of the disgruntled team, I echo Roy's comments. This is heavily impacting our DEV cycle; roughly 1 in 3 deployments are failing because of this, and given that we can do up to 60 deployments in a day, that's no negligible chunk. ANY workaround or fix to this would be appreciated.

Just another voice in the wilderness... have a team upset that their deploy fails because the ssh task doesn't work on windows... and they can't prevent it from running on windows (you should be able to select a custom attribute like operating system at least...)

Is anyone actually doing anything with this?
It is becoming more and more critical, and ass per Jeff above, I cannot believe it doesn't seem to be being processed by anyone at Atlassian.
We have a temporary fix (kludge) for anyone reading this, basically we schedule a build which contains a 10 minute wait on the platform(s) we don't want the deploy on so that the only available agent when the scheduled deploy happens is the remaining platform we want the build on. It's horrible and unextensible.

Is this even acknowledged as a bug and going to be worked on at some time????