Jobs skipped when NEEDS job ran successfully

Describe the bug One or more jobs are skipped in a workflow when run after successfully running a job matching following conditions:

• Job has NEEDS dependency on one or more preceding jobs. (i.e. needs: [job1, job2])
• Job has if condition specifying behavior when NEEDS jobs are skipped. (i.e. if: always() && needs.job1.result == ‘skipped’)
• Preceding job is skipped (i.e. job1)

To Reproduce Create a workflow as follows:

name: Skipped Job Test

on:
  workflow_dispatch:
  
jobs:
  Skipped-Job:
    name: skipped job
    runs-on: [self-hosted]
    if: 1 != 1
    steps:
    - name: write to console 1
      run: Write-Host "I should be skipped"

  Needs-Job:
    name: needs conditional job
    needs: Skipped-Job
    if: always() && needs.Skipped-Job.result != 'failed' # this should run eventhough needs the skipped-job
    runs-on: [self-hosted]
    steps:
      - name: write to console 2
        run: Write-Host "Needs-Job completed"
  
  Next:
    name: Next job
    needs: Needs-Job
    # if: always() && needs.Needs-Job.result == 'success' # uncommenting this condition causes the job to not be skipped
    runs-on: [self-hosted]
    steps:
      - name: write to console 3
        run: Write-Host "I should print whenever Needs-Job succeeds"

Expected behavior I’d expect the job “Next” to run, because the preceding job " Needs-Job" is completed successfully and is the only condition for this job to run (it needs Needs-Job), it is however skipped. uncommenting the 3rd line in that job is a fix, but this feels hacky and shouldn’t be needed.

Runner Version and Platform

Current runner version: ‘2.298.2’

Running on: Windows Server 2022 Standard Version 21H2 OS build 20348.1006

[kgreav]

This is really weird behaviour. As noted here this definitely seems to be a bug (why are we all just running into this now? did everyone suddenly decide to use job ifs?).

A job being skipped seems to be treated as failed, so success() doesn’t work for follow on jobs. As documented in the discussion, you should instead use ! failure() which works a treat, but you then have to propagate it to all descendant jobs even if they don’t directly depend on the skipped job, which is very confusing.

You should fix success() to not include skipped jobs, as skipped really should mean “this wasn’t needed”, not “this failed”. And needs checks should only occur on the explicitly listed jobs, not ancestors of those jobs.

[ywilkof]

Experienced this as well. Unless explicitly documented, this feels like a bug. Current behavior is unintuitive as well as cumbersome to develop, since one has to push the if clause to all descendent jobs just because of one skipped ancestor.