CODEWITHSUNDEEP
github-actions
kymkcay
kymkcay

Reputation: 166

How can I require conditional workflows to pass without blocking pull requests from being merged?

When setting up CI with GitHub Actions I want two things:

  1. To require workflows (e.g. backend unit testing) to pass before allowing pull requests to be merged.
  2. To conditionally run workflows (e.g. backend unit testing only when a pull request changes files in the backend directory of my project).

In isolation these requirements work well:

  1. I use branch protection settings to require status checks to pass before pull requests can be merged.
  2. I can use the GitHub Actions workflow syntax to specify which paths should trigger a workflow.

Combined there is a problem: If a pull request doesn't touch the backend files, then that workflow never runs and the status check never passes.

I would like to be able to have the best of both worlds: allow merge when all workflows which run pass. How can this be achieved?

Upvotes: 2

Views: 1549

Answers (1)

kymkcay
kymkcay

Reputation: 166

There are a few possible workarounds to achieve the behaviour of only requiring triggered workflows to pass:

  1. Skip jobs within a workflow by making them conditional instead of the whole workflow. This works because skipped jobs are considered a success.
    • Requires the use of third-party actions (e.g. paths-filter for conditions on changed paths).
    • Upsides
      • Runner minutes are minimised because no extra runner is introduced. If you're working in a private repository this important for billing (see details of GitHub Actions pricing).
    • Downsides
      • DX - you can't tell at a glance which workflows ran fully on a PR.
      • DX - you have to introduce and maintain conditional job logic into workflows.
      • Runners are spun up needlessly just to skip the run.
  2. Introduce a workflow which checks the status of other workflows on a pull request and passes when they all do. Make this the only required status check under branch protection.
    • The third-party action wait-for-status-checks does this nicely out of the box.
    • Upsides
      • DX - it's clear at a glance which workflows actually ran.
      • DX - Simple to configure the new workflow and doesn't require introducing extra logic into others.
      • Runners aren't spun up needlessly just to skip a run.
    • Downsides
      • Introduces an extra runner which will always run at least as long as the longest workflow on a PR. In effect this doubles the runner minutes of your longest workflow. If you're working in a private repository this important for billing (see details of GitHub Actions pricing).
  3. Create a dummy workflow job of the same name which runs when the required workflow doesn't. This used to be recommended in GitHub's documentation on handling skipped required checks, but was removed because it creates a lot of maintenance burden and introduces odd cases where both checks can run on a pull request.

References:

Upvotes: 2

Related Questions