Ubuntu – Once reliable GitHub Action Workflow now deploys non-runnable Azure Function Apps

I have a GitHub Action workflow that previously deployed Azure Function Apps reliably. These Function Apps target Windows.

The workflow still seems to run the deployment without issue, but once deployed, the list of functions it contains no longer shows in the Azure Portal and sometimes a banner message shows above where the functions would be listed that states We were not able to load some functions in the list due to errors. Refresh the page to try again. See details, with the details showing the following error message: An unexpected error has occurred..

Application Insights does not capture any details for the failure.

If deployed to azure manually from Visual Studio, the Function App deploys without issue and all the available functions are listed in Azure Portal as expected.

Any ideas what may have changed on GitHub / Azure’s side that causes the breakage and how I might fix it?

This is the workflow script:

on:
  workflow_call:
    inputs:
      client_config_dir:
        required: true
        type: string
      functionapp_name:
        required: true
        type: string
      functionapp_config_source_filename:
        required: true
        type: string
      functionapp_config_dest_filename:
        required: true
        type: string
      functionapp_csproj_name:
        required: true
        type: string
      dotnet_version:
        required: true
        type: string
    secrets:
      publish_profile:
        required: true

jobs:

  build-test:
    name: Build & Test
    runs-on: ubuntu-latest
    steps:

    - name: Checkout
      uses: actions/checkout@v3

    - name: Copy client specific configs
      run: |
        cp "source/Config/${{ inputs.client_config_dir }}/test.settings.json" "source/Config/test.settings.json"
        cp "source/Config/${{ inputs.client_config_dir }}/shared.settings.json" "source/Config/shared.settings.json"
        cp "source/Config/${{ inputs.client_config_dir }}/${{ inputs.functionapp_config_source_filename }}" "source/Config/${{ inputs.functionapp_config_dest_filename }}"

    - name: Setup .NET
      uses: actions/setup-dotnet@v3
      with:
        dotnet-version: ${{ inputs.dotnet_version }}

    - name: NuGet package cache
      uses: actions/cache@v3
      with:
        path: ~/.nuget/packages
        key: ${{ runner.os }}-nuget-${{ hashFiles('**/packages.lock.json') }}
        restore-keys: |
          ${{ runner.os }}-nuget-

    - name: Restore dependencies
      run: dotnet restore source/LogisticsAutomation.sln

    - name: Build full solution
      run: dotnet build source/LogisticsAutomation.sln --no-restore --configuration Release

    - name: Test full solution
      run: dotnet test source/LogisticsAutomation.sln --no-build --configuration Release --verbosity normal

    - name: Generate function app artifacts
      run: dotnet publish source/${{ inputs.functionapp_csproj_name }}/${{ inputs.functionapp_csproj_name }}.csproj --no-build --configuration Release --output ./deploy

    - name: Store artifacts
      uses: actions/upload-artifact@v3
      with:
        name: deploy
        path: deploy

  deploy:
    name: Deploy
    needs: build-test
    runs-on: ubuntu-latest
    steps:

    - name: Retrieve artifacts
      uses: actions/download-artifact@v3
      with:
        name: deploy
        path: deploy

    - name: Deploy function app
      uses: azure/functions-action@v1
      with:
        app-name: ${{ inputs.functionapp_name }}
        package: deploy
        publish-profile: ${{ secrets.publish_profile }}

Please note that while using ubuntu-latest in the workflow, the Function App itself is Windows. There’s a number of Functions Apps and the same behavior is observed for both app service and consumption hosted Function Apps.

Differences:

The only obvious difference I can see between the deployment methods is that the GitHub workflow will result in a runtimes directory being deployed in the root with both win and unix child directories, where as the Visual Studio deployment will result in a .azurefunctions with a runtimes child directory containing only a win child itself.

GitHub Workflow files:

Visual Studio files:

Interestingly the solution is all net8.0 and the GitHub workflow has resulted in a net6.0 folder under the deployed runtime, which makes me think dotnet publish may be picking up the wrong version somehow. All *.csproj files have <TargetFramework>net8.0</TargetFramework> and the workflow param is dotnet_version: 8.0.x.

Searching for net6.0 in working folder I find the following which may be relevant – objDebugnet8.0WorkerExtensionsWorkerExtensions.csproj:

<Project Sdk="Microsoft.NET.Sdk">
    <PropertyGroup>
        <TargetFramework>net6.0</TargetFramework>
        <Configuration>Release</Configuration>
        <AssemblyName>Microsoft.Azure.Functions.Worker.Extensions</AssemblyName>
        <CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>
    </PropertyGroup>

    <ItemGroup>
        <PackageReference Include="Microsoft.NETCore.Targets" Version="3.0.0" PrivateAssets="all" />
        <PackageReference Include="Microsoft.NET.Sdk.Functions" Version="4.3.0" />
    </ItemGroup>

    <Target Name="_VerifyTargetFramework" BeforeTargets="Build">
        <!-- It is possible to override our TFM via global properties. This can lead to successful builds, but runtime errors due to incompatible dependencies being brought in. -->
        <Error Condition="'$(TargetFramework)' != 'net6.0'" Text="The target framework '$(TargetFramework)' must be 'net6.0'. Verify if target framework has been overridden by a global property." />
    </Target>
</Project>

Experiments:

Oryx:

I tried setting scm-do-build-during-deployment and enable-oryx-build to see if that made any difference, but the same issue occurred:

- name: Deploy function app
  uses: azure/functions-action@v1
  with:
    app-name: ${{ inputs.functionapp_name }}
    package: deploy
    publish-profile: ${{ secrets.publish_profile }}
    scm-do-build-during-deployment: true
    enable-oryx-build: true

Newer action versions:

I also noticed that newer versions of most actions were available now e.g. actions/setup-dotnet@v4, so I updated all actions to the latest available. This didn’t make any difference.

Local build and publish:

I note that when I run dotnet build and dotnet publish locally that both the .azurefunctions and runtimes folders appear in the root. So I wonder if the missing .azurefunctions may be the route of my issue when deployed via GitHub actions.