Allow full workflow to be selected as required status checks

[finolacahill]

Currently you need to manually specify each job which should block merging per repo in Github Actions CI.
This is time consuming and frustrating. We're working around this by having each workflow contain a wrapper job which needs every other job and checks the status of each of its' needs. i.e. :

Why can't I just specify that my whole pull_request work flow is required to pass? Larger question, why wouldn't be whole pull_request flow be required to pass? (in terms of best practices, it's pretty counter-intuitive) You can imagine how long and unwieldy the 'container' job gets as workflows get longer

As an intermediatory step, you could allow a job that calls a reusable work-flow to be set as a status check. Currently you have to select each job that that workflow calls i.e. :

I have the 'call-workflow' job, which calls my reusable workflow 'pull_request' from another workflow 'dispatch', but I can not just specify call-workflow as my status check, I have to specify each of the jobs it will then call. This is silly.

[ethomson]

Thanks for the feedback @finolacahill - this makes a lot of sense. As the number of workflows and jobs grows, so too does the complexity here in managing them. I'll make sure that this is on the backlog for us to investigate.

[Keshapally]

Hi All,

Any updates on this feature or any alternative solution ?

[finolacahill]

It looks like ethomson doesn't work at github anymore. @tuves did anyone take over this issue when ethomson left? Thanks.

[tuves]

@finolacahill It’s on the internal backlog of work for the team to look at but there isn’t anything I can share yet, as it’s not on our public roadmap. @chrispat would be your go-to person for all things GitHub Actions

[finolacahill]

Thanks @tuves , I appreciate the update.

[Dr-Electron]

Any updates on this?

[airtower-luna]

This would be particularly useful to have where job names are expected to change now and then, for example in a matrix testing with different versions of a dependency and the version to the matrix job name for clarity.

[ghost]

Great suggestion.

I have an Azure DevOps experience and I was expecting to select a full Workflow definition in this area.

The search for "Status Check" is very messy... I didn't designed my Job names to be unique accross all my different Worklow, so I can't easly understand which job I selected.

[jmurret]

we just ran into this and are going to workaround it in the meantime by adding a job at the end of the workflow that needs the others called <workflow name>-success and specify this in the branch protection rules.

[altano]

I tried this and it doesn't work. The final job will be marked as skipped, and even if required, skipped jobs won't block anything. Required status checks block while in the following states: "not yet run" or "in progress" or "failed". "success" or "skipped" pass the required status check.

[asos-tommycouzens]

Hi,

We would really like this too. The workaround jmurret does not work exactly for us, since if it fails at an earlier job it will show the check as still pending and not as failed, since our job as never run. In addition,. when we have workflows with many steps it show as a crazy number of checks (in our case over 100) which creates a lot of noise when we are only running 6 workflows.

The above screenshot says it is waiting on the Deprovision main job, but actually the workflow looks like this:

As you can see its actually failed, but it just has not reached the Deprovision Main job and so GitHub still marks it as pending.

[scottwithbanner]

Would love a way to configure the workflow to report as a single check on the PR, rather than one check per job.

[asos-michaelwaterfall]

Here's an example workaround that's working for us, and deals with job skips, cancellations and failures.

check-workflow-status:
  name: Check Workflow Status
  runs-on: ubuntu-latest
  needs:
    [
      check-labels,
      run-tests,
      deploy,
    ]
  if: always()
  steps:
    - name: Check Workflow Status
      run: |
        exit_on_result() {
          if [[ "$2" == "failure" || "$2" == "cancelled" ]]; then
            echo "Job '$1' failed or was cancelled."
            exit 1
          fi
        }
        exit_on_result "check-labels" "${{ needs.check-labels.result }}"
        exit_on_result "run-tests" "${{ needs.run-tests.result }}"
        exit_on_result "deploy" "${{ needs.deploy.result }}"

Which allows a single required check to cover the whole workflow.

An added bonus of this is that checks are now driven by the workflow definition; you can introduce new requirements that gradually make their way into people's PRs. Prior to this, if you add a new required check on a ruleset, it will become instantly required for all open PRs, regardless whether the new job itself has made its way into their branches.

[BrianValente]

Works great, thank you!

[ChristophS-md]

Based on this, I did it DRYer and added a check that needs is complete. (And as for the allowed states, I don't see any reason to allow anything but "success".)

check_overall_status:
  needs: …
  if: always()
  runs-on: ubuntu-latest
  steps:
  - name: Checkout
    uses: actions/checkout@v6
    with:
      …
  - name: "check that this job's `needs` is set to exactly all other jobs"
    env:
      THIS_WORKFLOW_FILE: '.github/workflows/test.yml'
      THIS_JOB_NAME: check_overall_status
    run: |-
      diff --minimal --report-identical-files \
        <(yq -r '.jobs | keys() | .[]' <"$THIS_WORKFLOW_FILE" | sort | grep --line-regexp --fixed-strings --invert-match -- "$THIS_JOB_NAME") \
        <(yq -r '.jobs.test.needs[]'   <"$THIS_WORKFLOW_FILE" | sort)

  - name: check overall status
    env:
      JOBS_TO_CHECK_JSON: ${{toJSON(needs)}}
    run: |-
      printf '$JOBS_TO_CHECK_JSON == "%s"\n' "$JOBS_TO_CHECK_JSON" >&2
      jq --raw-output '
          [to_entries[] | select(.value.result != "success")]
          | map((.key + " has status " + (.value.result//"null") + "\n") | halt_error(1))[]
      ' <<<"$JOBS_TO_CHECK_JSON"