Status checks "required if run"

[pmeier]

TL;DR

Is it somehow possible to change the branch protection from status checks that are required to “required if run”?

---

I heavily make use of the

on:
  pull_request:
    paths:

for my different workflows for GitHub Actions. Thus, depending on what files were changed in the PR a different set of checks is run. I would mark most (if not all) of them as required before a PR is merged. Problem is, if I do that the PR also waits for checks that will not be run. Is it somehow possible to change this behavior so that a check is marked as required only if it is run?

[weide-zhou]

Hi @pmeier,

I’m afraid it’s not supported. If the checkrun is required, it has to be completed and return a status value.

mustpass729×118 7.32 KB

The only exception is if you’re an administrator, you can still merge the pull request.

Thanks.

[pmeier]

Hm, that is unfortunate. Problem with you approach is that the PR is marked as “not completed yet (yellow dot)” or failed forever, although that is not the case. I guess I’ll remove the branch protection rules in that case. Thanks for your input.

[tunetheweb]

Yes this is a real shame.

I’d like a “all tests run must pass” option, rather than a “these tests must run and pass (even though some of them may not be automatically started nor be relevant)” option.

[ayushxx7]

any new update on this?

[piotrekkr]

@pmeier @ayushxx7 You could try this workaround:

• put all those checks inside one workflow file
• DO NOT define paths: for pull request event
• create some initial job (e.g. init-job) that will decide what actual checks should run and which one should be skipped (based on changed paths) and set results as job output parameters
  • you can use this paths-changes-filter action to check what changed
• define each check so it will depend on init job (needs: init-job) and will only be run when output of init-job is set to correct value, e.g. if: needs.init-job.outputs.run_check1 == 'yes'

This way some check will run, and the rest will be skipped if path were not changed. GitHub treats skipped jobs as non blocking for PR merge so this should work fine I think.

[lijok]

Just found out this wasn't supported. This is incompatible with monorepos.

[fregante]

I have a solution that involves a separate job with needs:

  pass:
    needs: tests
    runs-on: ubuntu-latest
    if: always()
    steps:
      - name: "tests must not fail (status: ${{ needs.tests.result }})"
        run: exit ${{ needs.tests.result == 'fail' && '1' || '0' }}

You can set this as your Required job. It will be green unless the tests job explicitly fails.

You customize it and add further logic and steps if you need it to depend on multiple jobs and also want to fail on "cancelled" jobs.

This is the one I'm currently using, with a couple dependencies and different requirements:

  pass:
    # Use `always()` in every step so that every step runs and gives the full status of the requirements
    needs: [affected-check, tests]
    runs-on: ubuntu-latest
    if: always()
    steps:
      - name: "affected-check must be successful (status: ${{ needs.affected-check.result }})"
        run: exit ${{ needs.affected-check.result == 'success' && '0' || '1'  }}
        if: always()
      - name: "tests must not fail (status: ${{ needs.tests.result }})"
        run: exit ${{ needs.tests.result == 'fail' && '1' || '0' }}
        if: always()

[piotrekkr]

Adding required check that depends on other required checks, is run with condition always() and check statuses of each required check is also a solution. You could also simplify a bit steps imho like this:

  pass:
    needs: [affected-check, tests]
    runs-on: ubuntu-latest
    if: always()
    steps:
      - name: Fail on required check failure
        if: |
          needs.affected-check.result != 'success'
          || needs.tests.result != 'success'
        run: |
          echo 'Required checks results: ${{ toJSON(needs) }}'
          exit 1

Still it would be way easier if this was implemented by GitHub so workarounds would not be needed.

[fregante]

You could also simplify a bit steps imho like this:

Simplifies the code but degrades DX. The second example I posted clarifies what's expected and what's current, separately, directly from the collapsed logs, and the list can grow very easily.

This is what it shows: