I have a workflow that looks like the following:

name: Site - Build and Deploy FTP

on:
  push:
    branches: main
    paths:
      - 'src/Site/Site/**'
  workflow_dispatch:

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/[email protected]
      
      - name: Setup .NET Core
        uses: actions/setup-dotnet@v4
        with:
          dotnet-version: '6.0.x'
          include-prerelease: true
          
      - name: Install dependencies
        working-directory: src/Site/Site
        run: dotnet restore
        
      - name: Build with dotnet
        working-directory: src/Site/Site
        run: dotnet build --configuration Release
        
      - name: Publish
        working-directory: src/Site/Site
        run: dotnet publish -c Release -o ${{env.DOTNET_ROOT}}/myapp
        
      #substitute production appsettings entries to temp json file
      - name: App Settings Variable Substitution
        shell: bash
        run: | 
           cat ${{env.DOTNET_ROOT}}/myapp/appsettings.json | jq --arg my_secret ${{secrets.SQL_CONNECTION_STRING}} --arg email_secret ${{secrets.EMAIL_PASSWORD}} '.Config.SiteDb = $my_secret | .Config.EmailPassword = $email_secret' > newfile.json

It was working up until two weeks ago when it started failing on the substitute appsettings step. The weird part is that I didn’t change anything in the workflow. Also, I have a nearly identical workflow for another portion of the project which succeeds every time(the only difference in the .yml files is that it runs on a different project and subs out different settings from its own appsettings.json file.) Generally it will fails with a 127 error code, but the cat command will write the appsettings.json file to the console, so it is finding that file properly, so it must be the jq command it is having a problem with.

I tried removing the –arg options and substitution filters and replacing it with just “jq ‘.'” and that succeeds just fine. Then, I tried just doing “jq ‘.Config.SiteDb = 5 | .Config.EmailPassword = 9’ and that succeeds. So it seems like something with –arg is messing up on this particular runner?