Branch protection with workflow or matrix checks

[noirbizarre]

Hi 👋🏼

On multiple projects I work on I find myself locked by the same issue: it's not possible to make a workflow or a matrix job the merge condition for a protected branch.

Workflow as a condition

Given a workflow can be quite dynamic, selecting individual jobs as a merge condition seems counter-intuitive.
We have workflows depending on branch names (like you could have in the rather standard git-flow approach), we also have workflow depending on files changed (as it's possible to filter on the trigger event too). The result is that we can't simply say "I want this workflow success to be the merge condition for pull-requests", we need to select individual jobs and it's not compatible at all with conditional steps.

So, is it possible to allow a workflow success to be the condition to merge on protected branches ?

Matrix as a condition

Given build matrix can be very dynamic (we use it to parallelize tests and this can sometimes lead to up to 16 matrix sub-jobs), it's becoming on some project impossible to specify a merge condition. Is it possible to allow a matrix to succeed without having to select every sub-jobs by name (which can be really frustrating if you have a matrix producing 16 sub-jobs and multiple branches you want to rpotect) ?

Usability consideration

In both case, in addition to preventing being able to choose a merge condition, the fact that we need to do this work branch by branch can be a nightmare. Each time we have a workflow change, depending on the name (which is optional, is generated when not specified and can also change) instead of the ID leads to difficulties selecting it has merge condition. Plus, in case of renaming or matrix change, we have to follow the commit carrying the change to change the condition by branch on each merge. On big projects, this is a nightmare.

So adding Workflows (by filename/basename instead of the name even if this is the name displayed into the UI) and Matrix as merge condition would solve many issues on our projects (should I say on my projects because I have the issue with many clients, in different situations), add readability on status checks (expected status checks from a matrix build or from a workflow with parallelization is also quite hard to read), lower the cost of branch maintenance...

Is it something feasible ?

[shink]

Yes! I have the same problem. Looking forward to the improvement.

[danielgary]

So the easiest solution I can come up with is to add a final job in your workflow that "needs" the matrix steps. Then set your check on that job.

[demisx]

This approach fails when running of the matrix itself is conditional. PR gets stalled waiting for required checks to pass.

[taylorlroberts7]

Here is an example of the final job we added to our workflow that uses the matrix steps..

  # This allows us to have a branch protection rule for tests and deploys with matrix
  deploy-status:
    runs-on: ubuntu-20.04
    needs: [configure, deploy]
    if: always()
    steps:
      - name: Successful deploy
        if: ${{ !(contains(needs.*.result, 'failure')) }}
        run: exit 0
      - name: Failing deploy
        if: ${{ contains(needs.*.result, 'failure') }}
        run: exit 1

deploy is the job that uses a matrix 🙂

[noirbizarre]

I am currently doing the same but this comes with some drawbacks:

• longer wait time for workflow end. While most of the time it is not important, when you rely on your own custom workers it may force you to wait for the ending job longer than expected
• pricing: each time there is an ending job, we have the incompresible job setup and this added to billed time. If you are already in paying plan, this is not neglectable on some frequent builds

[renefritze]

Especially considering the final job likely takes 1 second to run and is billed for the full minute.

[StephenHodgson]

I agree, this should be implemented in the runner itself, where a more generalized status is returned.

[bmeeder22]

+1