Can´t deploy to ECS with the "DEPLOY AMAZON ECS SERVICE" step


We are trying to deploy to our Fargate Cluster with the “DEPLOY AMAZON ECS SERVICE” and everything seems to be good, the Task Role and the Execution Role have been used in other manual deploys without problem, but with Octopus it fails and it showing us this message:

“Resource template validation failed for resource TaskDefinitioncmaServiceTaskTest as the template has invalid properties. Please refer to the resource documentation to fix the template. Properties validation failed for resource TaskDefinitioncmaServiceTaskTest with message: #/RuntimePlatform: extraneous key [CPUArchitecture] is not permitted”

We have tried the options ARM64 and X86_64 but none of those work. Is it possible to have this step fixed or modify for this use case or at least have the custom code like the one used for this step to try to fix the issue by ourselves?

Thanks in advance.

Hi @andres.carcamo!

Thanks for reaching out, and sorry to hear that you’re having issues with your ECS deployment. Looking at this, it appears that the step is sending CPUArchitecture, while AWS is expecting CpuArchitecture, resulting in the validation error you might be seeing. I’ll raise this with the steps team, and see if we can get this fixed up ASAP. As this does use our new step template framework, Octopus will be able to pull down the latest version of this step in the background, without the need for a upgrade.

I’ll be in touch when we’ve spoken to the team (they’re based in Australia, so it will likely be tomorrow by the time we’ve discussed it), and let you know the outcome.

1 Like

Hi @andres.carcamo!

Thanks for your patience on this one, we’ve been trying to replicate this, but it looks like the CPU/Cpu field naming doesn’t appear to be the full issue - we were able to otherwise successfully deploy using this step with the CPUArchitecture key. I wonder if there’s another issue causing the failure, then as a result of the failure, it’s performing additional validation and throwing this error, even though that was not what caused it to fail in the first place.

Are you able to send through the raw task log of this failed task, just to see if we can glean any more information from it? I’ve created a secure upload link HERE that you can use to send it over.

Thanks in advance, and I hope we can get this sorted out for you ASAP.

Hello @Justin_Walsh

Thanks for your response, we have reviewed all the values and error messages and the error was in our targetGroupARN, so it appears that the message we have seen about the architecture wasn’t the root problem and the deployment succeed even with the architecture error so by the moment we are good to go. Thank you very much again for the concern and sorry for the late of my response.