Dynamic configuration vs Github Required checks

Hi,

Some weeks ago, we started to switch our circleci configuration to dynamic configuration, as you can see here open-build-service/config.yml at master · openSUSE/open-build-service · GitHub

The issue that we are facing right now is that, we have a set of “required checks” to merge PR into master, and one of the “required” checks, will just run if some set of files were changed. Therefore we need as well a conditional way to require a specific check just if a specific workflow runs or not. Otherwise either I have to remove the “required check” or never have a PR with all checks “green” again :frowning:

Thanks

Victor

1 Like

currently working on a monorepo with many services and having the exact same problem, since the Github merge protection requires the admin to specify the exact job or workflow name, the path-filtering orb doesn’t work really well with it

If I have parallel workflows A and B and specify both on the Github required status check dashboard, the Github PR merge check will be stuck if I only trigger either workflow A or B (not both) based on path-filtering orb mapping.

I wonder if there’s a way on circleci (or from Github side) to dynamically use all existing workflow as a check rather than specifying it manually from the Github dashboard

2 Likes

I have the same issue. The way I did it for now is creating a all-ok job that I trigger at the end of my workflow:

    frontend:
        when:
            and:
                - << pipeline.parameters.test-frontend >>
                - not: << pipeline.parameters.test-backend >>
        jobs:
            - test-e2e
            - test-frontend
            - test-pdf
            - test-js-utils
            - all-ok:
                  requires: [test-frontend, test-pdf, test-e2e, test-js-utils]

but it forces me to specify each case individually (“when (and (test-frontend, not test-backend))” instead of just “when test-frontend”) otherwise I would have the all-ok job run in another workflow and allow merge on github.

Now I’m adding more paths and dependencies (run test-frontend and test-pdf when js-utils/* is modified) and the configuration gets really tedious to write by hand…

I have this same problem and I’m trying to think of a solution to it.

I’ve been thinking about implementing a similar solution that works with workflows.
I don’t want a single workflow for all our code - it would be unmanageable.

I’m surprised that CircleCI hasn’t come up with a good solution here.

Hmm … interestingly, the Circletron orb might solve this issue we have with CircleCI and Github branch protection.

It will replace jobs that are not required with echo statements, so you can require any number of final outputs.

The negative side of that is that you’ll see a huge spam in GitHub in big monorepos

It would be nice to have an official response from CircleCI as this affects everyone working with monorepos and github checks…

2 Likes

It would be nice to have an official response from CircleCI

yes definitely. But getting no response is a powerful response in itself .

Anyone come up with any new / creative solutions to this. I had the same thought (in terms of dummy checks), but doesn’t seem like a good idea for various reasons.