Retrieving publishing credentials failed with HTTP status 400 - Bad Request

usability
(Scott) #1

Hi

I recenntly converted an Octopus web app deployment process step to use a Service Principal Account (as opposed to the retired SSL cert auth method)

The deployment is failing with the error

Retrieving publishing credentials failed. Publish-settings URI: https://management.azure.com/subscriptions/<sub GIUD>/resourceGroups/partnerapi-rg-production-wr/providers/Microsoft.Web/sites/partnerapi01-webapp-payin-production/slots/#{slot}/config/publishingCredentials/list?api-version=2016-08-01

System.AggregateException: One or more errors occurred. ---> System.Exception: Retrieving publishing credentials failed with HTTP status 400 - Bad Request

While similar to other posts, this does not seem to be due to an Azure backend outage and is not being caused by using cert based auth as this is what we are switching away from

Looking at the TeamCity the is trying to call/invoke this I see

[Octopus Deploy] Running command: octo.exe promote-release --server https://octopusdeploy.<domain>.com --apikey SECRET --project Partner API --enableservicemessages --from staging.<domain>.com --deployto <domain>.com --progress --deploymenttimeout 01:00:00 --variable slot:staging --force

But in the Octopus logs I’m seeing the slot not as the one being passed bu the var in the process step (#{slot})?

/slots/#{slot}/config/publishingCredentials/list?api-version=2016-08-01

Does anyone have any ideas ? All other jobs that were switched from cert auth to Service Pricipal seem to work ok, this is the only sitcky one ?

Many thanks

_scott

(Kenneth Bates) #4

Hi Scott,

Thanks for getting in touch! Passing in the slot value via the --variable argument in this command sets the value of a matching prompted variable. If the matching variable isn’t defined as type prompted, then this will be ignored, which sounds like might be happening in your case for this project. Can you confirm if this slot variable has type prompted (indicated by the icon shown below)?

If this is the case, it might be easier to set a standard environment-scoped variable (non-prompted) to control the slot, which would then negate the need to set this variable from your promote-release command in TeamCity.

I hope this helps, and I look forward to hearing back!

Best regards,

Kenny