Failed to check app setting propagation for SCM_DO_BUILD_DURING_DEPLOYMENT and ENABLE_ORYX_BUILD.

First observed yesterday, our deployment action is having some issues. We’re using node.js, our action is based on this template.

After Client.updateAppSettingViaKudu is called and returns 204, we get stuck in a timeout / retry cycle for about 3 minutes. See Github job log below.

Run Azure/functions-action@v1
  with:
    app-name: REDACTED
    package: .
    publish-profile: ***
    slot-name: REDACTED
    respect-pom-xml: false
    respect-funcignore: false
    scm-do-build-during-deployment: false
    enable-oryx-build: false
  env:
    AZURE_FUNCTIONAPP_NAME: REDACTED
    AZURE_FUNCTIONAPP_PACKAGE_PATH: .
    NODE_VERSION: 10.x
Successfully parsed SCM credential from old publish-profile format.
Using SCM credential for authentication, GitHub Action will not perform resource validation.
Sucessfully acquired app settings from function app (with SCM credential)!
Will archive . into /home/runner/work/_temp/temp_web_package_47007169786336567.zip as function app content
Will use Kudu https://<scmsite>/api/zipdeploy to deploy since publish-profile is detected.
Setting SCM_DO_BUILD_DURING_DEPLOYMENT in Kudu container to false
Update using Client.updateAppSettingViaKudu
Response with status code 204
Warning: Failed to check app setting propagation for SCM_DO_BUILD_DURING_DEPLOYMENT, remaining retry 19
App setting SCM_DO_BUILD_DURING_DEPLOYMENT has not been propagated to Kudu container yet, remaining retry 19
Warning: Failed to check app setting propagation for SCM_DO_BUILD_DURING_DEPLOYMENT, remaining retry 18
...truncated...
Warning: Failed to check app setting propagation for SCM_DO_BUILD_DURING_DEPLOYMENT, remaining retry 1
App setting SCM_DO_BUILD_DURING_DEPLOYMENT has not been propagated to Kudu container yet, remaining retry 1
Warning: Failed to check app setting propagation for SCM_DO_BUILD_DURING_DEPLOYMENT, remaining retry 0
App setting SCM_DO_BUILD_DURING_DEPLOYMENT has not been propagated to Kudu container yet, remaining retry 0
Warning: App setting SCM_DO_BUILD_DURING_DEPLOYMENT fails to propagate to Kudu container
Setting ENABLE_ORYX_BUILD in Kudu container to false
Update using Client.updateAppSettingViaKudu
Response with status code 204
Warning: Failed to check app setting propagation for ENABLE_ORYX_BUILD, remaining retry 19
App setting ENABLE_ORYX_BUILD has not been propagated to Kudu container yet, remaining retry 19
Warning: Failed to check app setting propagation for ENABLE_ORYX_BUILD, remaining retry 18
App setting ENABLE_ORYX_BUILD has not been propagated to Kudu container yet, remaining retry 18
...truncated...
Warning: Failed to check app setting propagation for ENABLE_ORYX_BUILD, remaining retry 1
App setting ENABLE_ORYX_BUILD has not been propagated to Kudu container yet, remaining retry 1
Warning: Failed to check app setting propagation for ENABLE_ORYX_BUILD, remaining retry 0
App setting ENABLE_ORYX_BUILD has not been propagated to Kudu container yet, remaining retry 0
Warning: App setting ENABLE_ORYX_BUILD fails to propagate to Kudu container
Package deployment using ZIP Deploy initiated.
Deploy logs can be viewed at REDACTED
Successfully deployed web package to App Service.
Successfully updated deployment History at REDACTED
Response with status code 204
Response with status code 204
Response with status code 204

Here’s some additional information.

• The deploy itself seems to go as expected. But the retry cycle is significantly slowing down our releases.
• We’ve observed this happening on both production & staging deploy slots.
• We’ve observed this with both Windows & Linux Function Apps.
• No similar issues are observed when deploying to the function app via VS Code (running in a dev docker container).
• No changes were made to our workflow files since the last time it was working properly.

Here’s a few things I’ve tried, to no effect.

• Explicitly setting the scm-do-build-during-deployment and enable-oryx-build in the workfile (both true & false).
• Knew it was probably unrelated, but tried tweaking the NODE_VERSION from 12.x to 10.x

I’d be happy to provide more information on request. Thanks for your help!

[kpm-at-hfi]

Should this issue be “idle”? I think we’re just waiting around to see it get fixed.

[keesschollaart81]

Same here with a Python using this template and a brand new Azure Functions with Python runtime 3.8 (although other versions behave similar).

It seems due to recent changes as reverting back to v.1.3.1 fixes it:

    - name: 'Run Azure Functions Action'
      uses: Azure/functions-action@v1.3.1