Central Directory corrupt error when deploying zip with WEBSITE_RUN_FROM_PACKAGE = 1 on linux

[mpalmahsf]

We're trying to migrate our Node.js apps from Windows to Linux. We've been using WEBSITE_RUN_FROM_PACKAGE=1 without any problems but are now running into issues with our Linux deployments. Getting the following deployment error on our api app when trying to run from a zip package on our Linux app plan.

{
    "details_url": null,
    "id": "",
    "log_time": "2024-08-02T18:14:30.8488499Z",
    "message": "Central Directory corrupt.",
    "type": 2
}

Our github deployment action script looks like this.

      - name: Azure CLI script
        uses: azure/CLI@v2
        id: azure-cli
        with:
          azcliversion: 2.62.0
          inlineScript: |
            az extension add --name webapp

            az storage container create -n $CONTAINER --account-name $STORAGE_ACCOUNT
            az storage blob upload      -f release.zip    --account-name $STORAGE_ACCOUNT -c $CONTAINER -n release

            ZIP_URL=$(az storage blob generate-sas --full-uri --permissions r --expiry ${{ env.expiry }} --account-name $STORAGE_ACCOUNT -c $CONTAINER -n release | xargs)

            az webapp deploy --resource-group $GROUP --name $WEBAPP --src-url "${ZIP_URL}" --type zip

            az storage container delete -n $CONTAINER --account-name $STORAGE_ACCOUNT

Again this works when deploying to Windows but gives the "Central Directory corrupt." error on Linux. Zip deployments also work when I upload the same zip file directly to the /home/data/SitePackages/ within the scm file manager. We're deploying from storage accounts to get around private endpoints on our resources.

Hoping I'm not stuck here.

[ShilpiRachna1]

This issue has been fixed in the service and deployed. Can you please confirm if it is resolved for you or you are still seeing this issue

[mpalmahsf]

This issue has been fixed in the service and deployed. Can you please confirm if it is resolved for you or you are still seeing this issue

Sorry I haven't been able to test this as our team has moved over to self hosted runners so we no longer require the Azure cli method of deployment