That’s a wild hack, lol. Would you mind sharing what your dummy job looks like? Thanks! For example, does it still start the container and have all of that overhead?

Something like

name: Dummy
on: push
jobs:

lint:

runs-on: ubuntu-latest

steps:

- name: Do nothing

run: exit 0

build:

runs-on: ubuntu-latest

steps:

- name: Do nothing

run: exit 0

I would not really call such hack a sane solution, but would rather see native implementation skipping checks for pull requests that do not touch paths defined for the action pull request event.

It may be dicey, but as it stands @samchou19815’s method of always triggering the dummy jobs that are named the same as the real jobs appears necessary to enable requiring different checks for different code paths. For example, requiring some tests to pass for changes to one service, but a different set of tests or no tests at all for another service or updates to the docs.

When there are multiple checks registered on the pull request with the same name, they all have to pass to fulfill the requirement. Also, the dummy job and the real job both start up at about the same time, so there’s no real window where the dummy has a chance to finish and allow merging before the real job starts up.

I call my dummy “automerge”

name: Automerge
on:
  pull_request:
    branches:
      - master
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - name: Exit with success
        run: exit 0

For anyone wondering, you can do this with the paths-filter action. It runs a job to check which path changed (checkout not needed for this job, which is a plus), then the following jobs will conditionally run or skip. Then you can mark them all as required.

  <a href="https://github.com/dorny/paths-filter#conditional-execution" target="_blank" rel="noopener nofollow ugc">GitHub</a>

dorny/paths-filter

Conditionally run actions based on files modified by PR, feature branch or pushed commits - dorny/paths-filter

I understand it’s quite an old ticket, but we have actually created a new GitHub Action for this use case.

  <a href="https://github.com/upsidr/merge-gatekeeper" target="_blank" rel="noopener nofollow ugc">GitHub</a>

GitHub - upsidr/merge-gatekeeper: Get better merge control

Get better merge control. Contribute to upsidr/merge-gatekeeper development by creating an account on GitHub.

Merge Gatekeeper is still in its early days, but it comes with a simple mindset that all jobs that ran should be in a success state. Merge Gatekeeper’s job is to wait and check other job status, and only becomes successful when all other jobs ran to completion and in a success state.

With that simple logic, you will only need to add a new Action setup using Merge Gatekeeper to your monorepo, and set it as the only required job - no other jobs need to be marked as required. As mentioned, the assumption is that no job should be in failed state, but this works nicely without any complex Action definitions.

If you need more granular control and ignore some failed state, it may be better handled with the solution @cscleison has referenced above, which looks great for some paths based branching 👍

This worked great, thank you

Anything we can do to reopen the conversation about this? It's quite confusing that the hacky solution is marked as an answer and the only other options are actions that overwrite the native GitHub logic.

It should be natively possible to configure the checks in a way that actions that don't run for a specific branch/PR. I.e. don't allow merging when an action fails instead of allowing merging if all actions succeed.

I ran into this issue now as well when developing a monorepo with different pipelines triggering depending on which parts of the code is touched. It would be useful to be able to configure checks as required only if a pipeline runs

I want to voice my frustration as well. I don't want to run my E2E tests and other code quality checks if I've updated the documentation.
The GitHub documentation that states that the status checks should not be mandatory in this case is absurd, in my opinion. They should be mandatory based on a given set of conditions!

I wanted to bring up the fact that jobs that use the matrix strategy are a bigger headache, where there's no way to add a check on the whole matrix, the required_status_checks have to be defined on the atomic instantiation of the matrix. I'd like to be able to depend on the whole matrix, and not have to list out every permutation. The "no-op" dummy job approach works, but it's a hack AND I have to duplicate my matrix semantics in that job and keep it in sync.