Could not find platform linux-x64 for Calamari.AzureWebApp

[ben.hodges]

Hi Patrick,

We haven’t migrated the variables to git so there isn’t a variables.ocl file available.

I have however uploaded a file showing you the octopus agent variables, hope that helps.

thanks,
Ben

[donny.bell]

Hi @ben.hodges,

Thank you for getting back to us.

Apologies for the inconvenience. It looks like the upload succeeded, but we had an issue processing the file on our end. Can you attempt the upload once more?

Let us know once you’ve had a chance to upload again.

Best Regards,
Donny

[ben.hodges]

Hi Donny,

No problem, i’ve uploaded just now.

thanks,
ben

[donny.bell]

Hi @ben.hodges,

Thank you for re-uploading that. I can confirm we are able to view the file now.

I’ll get with @patrick.smergut once he signs on for the day (as he is US-West) to have a look at his testing.

We appreciate your patience while we continue to investigate.

Best Regards,
Donny

[patrick.smergut]

Hi Ben,

Thanks for providing us with the additional details. I think we have potentially found what is causing this behavior, but I’m curious to see if it aligns with your configuration.

In the parent step Deploy an Azure Web App I see the Role Execution Plan (Octopus.Action.TargetRoles in your OCL) is set to PaymentsApiHost. If you review your Targets under Infrastructure > Targets and filter for this role using Show Advanced Filters and selecting PaymentsApiHost as the role, it should give you all targets under this role.

Click into the target and see if there’s anything set under Communication > WorkerPool. For example:

If there is a Worker Pool set here, then this may be overriding what’s set in the step for the Worker Pool. So, depending on what you find here, you might try clearing this or changing the Worker Pool to see if it changes the behavior you’re seeing.

Let me know what you find!

Best regards,
Patrick

[ben.hodges]

Hey Patrick,

I forget that setting exists, just assume someone would set this at the step level not target. I’ve updated the pool to use the default pool as it was set to a different one and that appears to have worked.

I’m not sure how that has effected it though when all we’ve done is change from a variable with it’s value set to the windows pool to a variable with it’s value set to the default pool. In theory in the logs this should reflected but instead it picks the linux pool.

If the target has a worker pool set to another pool then the variable change shouldn’t have effected it? It’s currently set to linux and i don’t want to change it to windows.

[clare.martin]

Hey @ben.hodges,

I am glad changing the value in the targets settings for the default pool for the target seems to have fixed this issue.

It should be that if the target has a worker pool set to another pool in the targets settings, then the variable change should not have affected it, I am not 100% sure if that is the case though. If its set to a non default pool in the target settings and you set that variable to use the default pool in the project settings then that target will never be picked.

It may be that the worker pool shown in the targets settings overrides anything you put in at project level, which is why I think that value in the target settings is shown as optional, if you don’t select a value for it the project settings are used.

What happens if you clear that value rather than have a value set, does the project pick the default pool?

I will pass this onto Patrick as he was the one who tested this and knows how he set the project up so he may be able to elaborate some more.

He will be online in a few hours but I realise we have not gotten a response out to you so far so I wanted to make sure you knew we had not missed this.

Kind Regards,
Clare