ZIP Deployment to Azure Function (via GitHub Action) fails

Question

I'm trying to set up continuous deployment from a GitHub Action for an Azure Functions App. Deployment to the App reliably fails with the error message Reset all workers endpoint responded with Response status code does not indicate success.

Note that we are not using Remote builds on Oryx (See configuration below). Instead, we build in our GitHub Action. Logs indicate that a remote build setup is launched anyways.

Deploying a ZIP file built on my system with the Azure CLI succeeds. I have a second Functions App which is similarly configured for which deployments work normally. Below, there are the full remote logs. If needed, I can supply the local debug logs of the GitHub action and the reference logs for the working deploy.

Updating submodules.
Preparing deployment for commit id 'c9e53ce3-a'.
PreDeployment: context.CleanOutputPath False
PreDeployment: context.OutputPath /home/site/wwwroot
Generating deployment script.
Running deployment command...
Running post deployment command(s)...
Triggering recycle (preview mode disabled).
Linux Consumption plan has a 1.5 GB memory limit on a remote build container.
To check our service limit, please visit https://docs.microsoft.com/en-us/azure/azure-functions/functions-scale#service-limits
Writing the artifacts to a squashfs file
Parallel mksquashfs: Using 1 processor
Creating 4.0 filesystem on /home/site/artifacts/functionappartifact.squashfs, block size 131072.

[===========================================================|] 71749/71749 100%

Exportable Squashfs 4.0 filesystem, gzip compressed, data block size 131072
	compressed data, compressed metadata, compressed fragments,
	compressed xattrs, compressed ids
	duplicates are removed
Filesystem size 156785.35 Kbytes (153.11 Mbytes)
	23.58% of uncompressed filesystem size (664842.73 Kbytes)
Inode table size 660653 bytes (645.17 Kbytes)
	26.04% of uncompressed inode table size (2537409 bytes)
Directory table size 687643 bytes (671.53 Kbytes)
	39.09% of uncompressed directory table size (1759117 bytes)
Number of duplicate files found 12382
Number of inodes 78741
Number of files 68145
Number of fragments 1171
Number of symbolic links  0
Number of device nodes 0
Number of fifo nodes 0
Number of socket nodes 0
Number of directories 10596
Number of ids (unique uids + gids) 1
Number of uids 1
	root (0)
Number of gids 1
	root (0)
Creating placeholder blob for linux consumption function app...
SCM_RUN_FROM_PACKAGE placeholder blob scm-latest-typststageapi__7bba.zip located
Uploading built content /home/site/artifacts/functionappartifact.squashfs for linux consumption function app...
Resetting all workers for api.staging.typst.app
Reset all workers endpoint responded with Response status code does not indicate success: 404 (Site Not Found).
Deployment Failed. deployer = GITHUB_ZIP_DEPLOY_FUNCTIONS_V1 deploymentPath = Functions App ZipDeploy. Extract zip.

This is how the deploy in the Action's workflow.yml is configured on GitHub:

      - name: "Run Azure Functions Action"
        uses: azure/functions-action@v1
        with:
          app-name: "typststageapi"
          package: ${{ env.AZURE_FUNCTIONAPP_PACKAGE_PATH }}
          enable-oryx-build: false
          scm-do-build-during-deployment: false
          publish-profile: ${{ secrets.AZUREAPPSERVICE_PUBLISHPROFILE_XXXXX }}

Extra data for Microsoft Employees:

• Functions App Name: typststageapi
• Reference working Functions App Name: typstapi

Answer 1

Hello, @Martin Haug - Thanks for providing additional info in the comments.

Since you're opting out of the Oryx build, the only supported deployment method to the Linux Consumption SKU is the External package URL (please review When to use it section). ZipDeploy extension and AppSetting WEBSITE_RUN_FROM_PACKAGE=1 are not supported by the Linux Consumption plan.

As such, the end result of your GitHub Actions workflow should produce the final build artifact (zip file containing the app and its dependencies) being uploaded to Azure Blob and its direct URL set as the value for the WEBSITE_RUN_FROM_PACKAGE app setting, as follows: WEBSITE_RUN_FROM_PACKAGE = packageURL

Could you try it out this way and share your findings?

The error message entailing resetting of workers & its possible correlation to a known bug is still something that we're not ruling out. And it sounds like you have an open support case for this issue too. Should the External package URL method fails, as the next step, I'd request you to contact us via email as the root cause may be more specific to your unique environment.