Allow full workflow to be selected as required status checks #12395
Replies: 7 comments 11 replies
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
Would love a way to configure the workflow to report as a single check on the PR, rather than one check per job. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.



Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
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.
Beta Was this translation helpful? Give feedback.
All reactions