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
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
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.
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.
Hola,
Is there any newer alternative?
My main concern is that our conditional jobs are running on a docker machine, and having the condition within the job’s steps require spinning up the environment before we can break from additional steps…
I just wanted to say that even though this solution works, it has the undesirable side-effect of cluttering the CircleCI UI with a bunch of jobs that are essentially no-ops. It makes it harder to nagivate to the job(s) that you might care about.
Here is an alternative workaround that will hopefully help with that. It was created with the goal of being more visually clear about what workflows are being “skipped”.
The main differences:
The branch protection rule uses the final job(s) in each path-filtered workflow
A stand-in workflow is triggered when a path-filtered workflow isn’t run
The stand-in workflow contains a stand-in job that has the same name as the final job in the path-filtered workflow
What if we could configure the main workflow (the one that prepares all the other workflows) to not be complete until all the workflows it spawned are complete? This way, we don’t need to wait for GitHub to support checking name wildcards; we can just add that main workflow name there.
That main workflow could also inherit the worst possible status of any spawned workflows (making it fail if any spawned workflows fail or cancel if spawned ones are canceled, succeed if all the spawned ones succeeded, etc.)
What if we could configure the main workflow (the one that prepares all the other workflows) to not be complete until all the workflows it spawned are complete?
IIRC, with the GitHub app integration, at least, you can choose to do exactly this - if you pick the option to not bubble the individual statuses back to the GH app separately, you’ll just get one workflow that will succeed or fail.
There are some obvious downsides here, though – for example, you can’t have check A succeeding required, but make check B or C succeeding optional.