Required status check job is skipped when one of the dependent job fails

[jaymalasinha]

Describe the bug
When one of the required dependent jobs fail in the workflow, the job requiring it is skipped.

• job "results" needs jobs needs: [build-one, build-two, test, test-more]
• when job "test" fails, "results" is skipped
• as "results" is a required status check for merge, it allows merging with failed dependent job

To Reproduce
Create the following workflow file:

name: build

on:
  workflow_dispatch:
  pull_request:
  push:

jobs:
  pre-requisite:
    runs-on: ubuntu-latest
    steps:
      - name: Get Req
        id: get-req
        run: echo "get req"

  build-one:
    name: build one
    runs-on: ubuntu-latest
    needs: pre-requisite
    steps:
      - run: echo "build-one"

  build-two:
    name: build two
    runs-on: ubuntu-latest
    needs: pre-requisite
    steps:
      - run: echo "build-two"

  test:
    name: Test initial
    needs:
      - pre-requisite
      - build-two
    runs-on: ubuntu-latest
    steps:
      - run: |
          echo "Testing builds"
          exit 1

  test-more:
    name: Test more
    needs:
      - pre-requisite
      - build-two
    runs-on: ubuntu-latest
    steps:
      - run: echo "Test more"

  results:
    runs-on: ubuntu-latest
    needs:
      - build-one
      - build-two
      - test
      - test-more
    steps:
      - run: echo "Workflows have succeeded!"

The job "results" is a required status check for merge. When the job "test" fails the job "results" is skipped

Expected behavior
The job "results" needs "test" to succeed, so I would expect it to not be skipped, as skipped status check allows merge.
Expect "results" to be skipped if any of the dependent jobs are skipped, like if "test" is skipped, but expect it to fail if any of the dependent jobs fail.

Runner Version and Platform

Current runner version: '2.303.0'

Ubuntu
22.04.2
LTS

Runner Image Provisioner
2.0.139.1

OS of the machine running the runner? OSX/Windows/Linux/...
Ubuntu

What's not working?

[ChristopherHX]

Workaround, let GitHub Actions throw an exception instead adding result skipped (you get no check status for the job, rerun will clear the old job status before execution of dependencies) I know this is not supported.

if: success() || ((!cancelled() || contains(needs.*.result, 'cancelled')) && fromjson('throw'))

The if condition is complex to preserve beeing able to cancel the job, if it is running.

Every job depending on that one won't get the chance to run if the condition fails even if you use always()

[jaymalasinha]

echo "Workflows have succeeded!"

Thank you @ChristopherHX for the workaround. With the workaround, If the pre-requisite job is skipped results get no check status.

[jaymalasinha]

updated the workaround to force fail for both failure and cancelled conditions

results:
    if: ${{ cancelled() || contains(needs.*.result, 'cancelled') || contains(needs.*.result, 'failure') }}
    runs-on: ubuntu-latest
    needs: [build-one, build-two, test, test-more]
    steps:
      - run: |
          echo "Some workflows have failed!"
          exit 1

That seems to also work with skipping "results" job when "pre-requisite" job is skipped

[ruvceskistefan]

Hey @jaymalasinha,
I see you have figured out how to fix your workflow for your case, I'll close this issue. If you think we need to reopen it just let me know.

[jaymalasinha]

Hey @jaymalasinha, I see you have figured out how to fix your workflow for your case, I'll close this issue. If you think we need to reopen it just let me know.

Hi @ruvceskistefan, We figured a workaround for the issue, but won't the expected behavior be that the status check job fails if any of its dependent jobs fail ? We did see that behavior in earlier workflows when we added a required status check job with multiple dependent jobs, but now noticed it started skipping the job incase of dependency failures. So reported it as a bug. We have to workaround it by negating the status check condition, which seems like a temporary hack. Can you please reopen, thanks.

[marcispauls]

same issue there, seems some breaking changes happened

[saiichihashimoto]

The workaround didn't work for me. While it failed when the dependent job failed, it also skipped when the dependent job succeeded, which is a massive regression.

[zorzella-tome]

The workaround is an ugly hack. I would love to have a proper way of doing this.