How to avoid CI if only certain files change?

Helpful Resources Tips, Tricks, and Hacks
1

All,

I probably should have asked this long ago, but I’m getting around to it now. Namely, on some of my GitHub Actions I have it set so that if in a PR the only files that change are say Markdown or JSON, I don’t run my CI (This is a Fortran codebase, so even python files are ignored as they are pre/post-processing.), a la:

on:
  pull_request:
    types: [opened, synchronize, reopened]
    # Do not run if the only files changed cannot affect the build
    paths-ignore:
      - "**.md"
      - "**.json"
      - "Python/**"
      - ".github/CODEOWNERS"
      - ".github/PULL_REQUEST_TEMPLATE.md"
      - ".editorconfig"

Is there something similar I can add to my .circleci/config.yml so that I can say "Don’t use my credits to run CI if all this PR does is update the CHANGELOG.md" or whatever?

2

circleci does not have any understanding of what has happened within your git repo, it just knows to execute the config.yml based on a webhook being called by GitHub.

It is possible to build only on a pull_request but you would have to pull down the current branch/version to work on and a past branch/version and then check what has changed, while also working out what type of pull request has been made. GitHub on the other hand has full access to your repo and so can do such checks directly.

The way around this would be to have GitHub do the processing that you outline above and then have it trigger the required circleci job only if needed. This can be done with a curl command and more details can be found here

 https://support.circleci.com/hc/en-us/articles/360050351292-How-to-trigger-a-workflow-via-CircleCI-API-v2
1 Like
3

@rit1010 Thanks. That was my suspicion, but I figured I’d ask. Since our CI build tests take 10-30 minutes, some users are annoyed when they change the README.md and have to wait for the CI to complete.

I know there is [skip ci] but for some reason, CircleCI seems to ignore that randomly. Sometimes it works, sometimes it doesn’t. And my fear is someone makes a [skip ci] PR and then hides a code change in it with a second commit and…CI avoided!

4

I wrote an orb that you may find useful -

Merges CircleCI’s path-filtering and continuation orbs to allow you to write separate configs. To avoid running a pipeline if, say, a README changes, try using the root module override and drop a .circleci/app.ignore file that contains README.md, e.g.

Let me know if you have any ideas for improvements or need clarification.

5

@bjd2385 Ahh. So I’d need to rename my .circleci/config.yml to .circleci/app.yml and then I could use a .circleci/app.ignore to ignore things in the root. And I suppose the pre-commit-hook as well for validation purposes?

6

@mathomp4 so CircleCI requires we have a .circleci/config.yml regardless, and what we can do from that config is call a continuation to read one additional config. So the structure would look like

.circleci/config.yml
.circleci/app.yml
.circleci/app.ignore

In .circleci/config.yml you’ll have one workflow with a job like the following -

setup: true

orbs:
  dynamic: bjd2385/dynamic-continuation@3.1.0

workflows:
  version: 2

  default:
    jobs:
      - dynamic/continue:
          context: orb-publishing
          modules: |
            .

where . is indicating that you want to call app.yml, which would contain your normal workflow. Kind of like the following (though it’s missing an app.ignore and it’s a couple versions behind) -

7

Ah and, as for the pre-commit hook, it’d probably be a good idea to use this, yes. It’ll reduce the additional configs and validate that locally, so you don’t find out later after pushing to your branch.