You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have a recently created function app in which the curl zip deployment doesn't work
curl -X POST -u <deployment_user> --data-binary "@<zip_file_path>" https://<app_name>.scm.azurewebsites.net/api/zipdeploy
Once I run the command, it automatically exits instead of waiting and uploading the zip file. Usually the command takes ~19 seconds and so it uploads the zip file, but on this specific app it is not doing so, nor is the command erroring out. It just successfully exits after I've put in the password for the deployment user. It is the same deployment user I use for the other functions so it shouldn't be a problem with the user.
There is no problem with the zip file as I'm able to deploy it through the AZ CLI. I also have other function apps to which I deploy with the exact same method and there is no issue with them. I've tried to delete and recreate the function app but I still have this problem.
https://<app_name>.scm.azurewebsites.net/api/settings shows that ENABLE_ORYX_BUILD and SCM_DO_BUILD_DURING_DEPLOYMENT are both true. The only differences in the settings I can see are:
My older apps have REMOTEDEBUGGINGVERSION,FUNCTIONS_RUNTIME_SCALE_MONITORING_ENABLED,WEBSITE_AUTH_LOGOUT_PATH,WEBSITE_AUTH_AUTO_AAD, but I did enable Azure AD on them for some time which I imagine would explain this. The other difference is that my application insights connection string on the new app has four key value pairs InstrumentationKey,IngestionEndpoint,LiveEndpoint,ApplicationId while my older apps have three InstrumentationKey,IngestionEndpoint,LiveEndpoint. I'd imagine this is a new format as I've not changed the app insights conn string. Other than this the settings are all the same except for where they're based on the app name. Additionally there's no logs generated from the deployment attempts (I've checked log analytics, the storage accounts and file system log streams) so I have not had any success in identifying the issue.
The text was updated successfully, but these errors were encountered:
I have a recently created function app in which the curl zip deployment doesn't work
Once I run the command, it automatically exits instead of waiting and uploading the zip file. Usually the command takes ~19 seconds and so it uploads the zip file, but on this specific app it is not doing so, nor is the command erroring out. It just successfully exits after I've put in the password for the deployment user. It is the same deployment user I use for the other functions so it shouldn't be a problem with the user.
There is no problem with the zip file as I'm able to deploy it through the AZ CLI. I also have other function apps to which I deploy with the exact same method and there is no issue with them. I've tried to delete and recreate the function app but I still have this problem.
https://<app_name>.scm.azurewebsites.net/api/settings shows that ENABLE_ORYX_BUILD and SCM_DO_BUILD_DURING_DEPLOYMENT are both true. The only differences in the settings I can see are:
My older apps have
REMOTEDEBUGGINGVERSION,FUNCTIONS_RUNTIME_SCALE_MONITORING_ENABLED,WEBSITE_AUTH_LOGOUT_PATH,WEBSITE_AUTH_AUTO_AAD
, but I did enable Azure AD on them for some time which I imagine would explain this. The other difference is that my application insights connection string on the new app has four key value pairsInstrumentationKey,IngestionEndpoint,LiveEndpoint,ApplicationId
while my older apps have threeInstrumentationKey,IngestionEndpoint,LiveEndpoint
. I'd imagine this is a new format as I've not changed the app insights conn string. Other than this the settings are all the same except for where they're based on the app name. Additionally there's no logs generated from the deployment attempts (I've checked log analytics, the storage accounts and file system log streams) so I have not had any success in identifying the issue.The text was updated successfully, but these errors were encountered: