Debug logs for the if condition of skipped jobs #20640

roryabraham · 2022-07-15T23:53:35Z

roryabraham
Jul 15, 2022

Coming from:

When a job is skipped because it’s if condition is not met, it’s very difficult to debug why that happened. It would be valuable to be able to see debug logs for the evaluation of the job-level if condition.

It’s sometimes possible to work around this by creating another job without a conditional and then creating steps with the same if condition that is used at the job-level for another job (Example). However, it’s inconvenient and not safe to assume that the evaluation of a condition is going to be the same at the job and step level.

Furthermore, when using a callable workflow, the job in the caller workflow will be skipped if none of the if conditions are met for the jobs inside the callable workflow, which was difficult to figure out. Maybe the UI could be altered to make this more clear, but the debug logs would have really helped.

Thanks! Curious to hear people’s thoughts.

dhirschfeld · 2022-11-13T12:55:51Z

dhirschfeld
Nov 13, 2022

My jobs are being mysteriously skipped even though I'm sure the if condition should evaluate to true. I have debug logging turned on but the only information the GitHub UI gives me is:

I would like the UI to provide me some way to ascertain why the job was skipped.

3 replies

dhirschfeld Nov 13, 2022

even though I'm sure the if condition should evaluate to true

The if condition does in fact evaluate to true if I put the same expression in a step rather than a job.

I'm at a bit of a loss as to how I'm supposed to debug an expression at the job level which evaluates to something different than it does at a step level?

dhirschfeld Nov 13, 2022

Posting my workaround in case it's helpful. I have a boolean input variable:

on:
  workflow_call:
    inputs:
      cond_a:
        type: boolean
        default: true

...and want to run a job if cond_a is true. I would've expected the below to work:

  run_if_cond_a_is_true:
    needs: [skipped_job]
    if: always() && ${{ inputs.cond_a }}

...but it didn't!?! If I used the condition always() && ${{ inputs.cond_a }} in a step, the step ran just fine.

My horrific workaround is to echo the inputs in a job and use the job outputs in my condition 🤮

  echo_inputs:
    runs-on: ubuntu-latest
    outputs:
      cond_a: ${{ steps.echo_inputs.outputs.cond_a}}
    steps:
      - id: echo_inputs
        shell: bash
        run: |
          echo "cond_a=${{ inputs.cond_a}}" >> $GITHUB_OUTPUT

  run_if_cond_a_is_true:
    needs: [echo_inputs, skipped_job]
    if: always() &&  needs.echo_inputs.outputs.cond_a

Surely using a boolean input variable in the if condition of a job should Just Work, exactly as you would expect it to, and exactly as it does work in a step?

ChristopherHX Nov 13, 2022

always() && ${{ inputs.cond_a }}

This is not supported (yet ?) and get converted to ${{ success() && (format('always() && {0}', inputs.cond_a)) }}.

Intentionally I would have tried it with the same invalid syntax as you have tried
Fair enough this would have worked in Azure Pipelines, because it uses a different rule to evaluate custom if conditions

ChristopherHX · 2022-11-13T15:07:37Z

ChristopherHX
Nov 13, 2022

I made an emulator for GitHub Actions, which shows you debug output of job level if conditions.
https://github.com/ChristopherHX/runner.server
You might be able to use it for troubleshooting issues with job level if conditions, I'm unaware of compatibility issues with job if conditions compared to the official GitHub Actions Services.

Weird enough, you can get the debug logs of job if conditions in Azure Pipelines (The current GitHub Actions Service Runner is a fork of it from 2019).

0 replies

tylermilner · 2023-06-24T02:54:32Z

tylermilner
Jun 24, 2023

I struggled with this for a few hours. Everything seemed like the if conditional on my "test" job should have evaluated to true, but the job was always being mysteriously skipped. For me, it had to do with how I set and accessed the should_run variable being used in the job's if conditional. Here are some examples of my failed and working configs:

Quotes around true value --> job "test" skipped (FAIL):

name: CI

on:
  - push
  - workflow_dispatch

jobs:
  run-check:
    runs-on: ubuntu-latest
    outputs:
      should_run: ${{ steps.set-output.outputs.should_run }}
    steps:
      - name: Set job output
        id: set-output
        run: |
          echo "should_run='true'" >> $GITHUB_OUTPUT
          
  test:
    runs-on: ubuntu-latest
    needs: run-check
    if: ${{ needs.run-check.outputs.should_run == 'true' }}
    steps:
      - uses: actions/checkout@v3

No quotes around true value --> job "test" skipped (FAIL):

name: CI

on:
  - push
  - workflow_dispatch

jobs:
  run-check:
    runs-on: ubuntu-latest
    outputs:
      should_run: ${{ steps.set-output.outputs.should_run }}
    steps:
      - name: Set job output
        id: set-output
        run: |
          echo "should_run=true" >> $GITHUB_OUTPUT
          
  test:
    runs-on: ubuntu-latest
    needs: run-check
    if: ${{ needs.run-check.outputs.should_run == true }}
    steps:
      - uses: actions/checkout@v3

Quotes around true when set, but not in conditional --> job "test" skipped (FAIL):

name: CI

on:
  - push
  - workflow_dispatch

jobs:
  run-check:
    runs-on: ubuntu-latest
    outputs:
      should_run: ${{ steps.set-output.outputs.should_run }}
    steps:
      - name: Set job output
        id: set-output
        run: |
          echo "should_run='true'" >> $GITHUB_OUTPUT
          
  test:
    runs-on: ubuntu-latest
    needs: run-check
    if: ${{ needs.run-check.outputs.should_run == true }}
    steps:
      - uses: actions/checkout@v3

Quotes around true in conditional, but not when set --> job "test" not skipped (SUCCESS):

name: CI

on:
  - push
  - workflow_dispatch

jobs:
  run-check:
    runs-on: ubuntu-latest
    outputs:
      should_run: ${{ steps.set-output.outputs.should_run }}
    steps:
      - name: Set job output
        id: set-output
        run: |
          echo "should_run=true" >> $GITHUB_OUTPUT
          
  test:
    runs-on: ubuntu-latest
    needs: run-check
    if: ${{ needs.run-check.outputs.should_run == 'true' }}
    steps:
      - uses: actions/checkout@v3

Making a copy of the skipped job without the if conditional and adding an additional step that echo'd the value being checked in the conditional was a great tip and helped me debug. Here is how that extra job looked in my case:

  test-debug:
    runs-on: ubuntu-latest
    needs: run-check
    steps:
      - uses: actions/checkout@v3
      
      - run: |
          echo "Check 'should_run'"
          echo "${{ needs.run-check.outputs.should_run }}"

Hopefully this helps someone running into a similar issue. I do agree that it would have made debugging this much easier if there was some sort of information in the web UI as to why a job is skipped.

1 reply

achimnol Jul 22, 2024

So the job outputs are always strings, no matter how they are set in previous jobs.
Context variables may have native types like boolean.

It becomes so confusing when evaluation of both job outputs and context variables come in a single 'if' expression.... 😞

Technically I could understand that there is no way to determine whether a job output value is intended to be a string or a native expression like context variables when they overlap and it would be safer to treat them as user-input strings, but this behavioral difference should be documented in a more clearer way, with concrete "pitfall" examples.

cliffchapmanrbx · 2023-10-20T21:39:15Z

cliffchapmanrbx
Oct 20, 2023

I'm disappointed that this has not been prioritized by the GitHub Actions team when it's a feature Azure DevOps Pipelines had half a decade ago.

On a daily basis my team receives requests from other engineers for help diagnosing why steps were skipped or workflows cancelled unexpectedly.

0 replies

dolfandringa · 2024-03-20T05:12:53Z

dolfandringa
Mar 20, 2024

I think its really bad practice to require users to modify the actions with additional jobs just to debug why a job was skipped. It makes the process really slow since you now need to go through code review process, just to debug, and you may potentially break the action for other users in the process. Being able to see why a step was skipped directly when running the action would speed up development a lot. Especially since github actions can be complex and powerful, the debugging tools need to reflect that.

0 replies

kzhou57 · 2024-08-02T23:04:32Z

kzhou57
Aug 2, 2024

This is an essential feature.

0 replies

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

GitHub Community

Debug logs for the if condition of skipped jobs #20640

{{title}}

Replies: 6 comments 4 replies

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

Select a reply

Debug logs for the if condition of skipped jobs #20640

Replies: 6 comments · 4 replies

Replies: 6 comments 4 replies