Github has a feature in their branch protections that allows for selected status checks to be required for a pull request to be merged into a branch.
When a workflow is not run within CircleCI, there is no status check provided to Github. There is no skipped status that CircleCI sends when a workflow is not run due to dynamic config in CircleCI. This can result in the PR being unable to merge as the required checks aren't satisfied.
CircleCI provides status checks for workflows and individual jobs. Github is looking for a status check from CircleCI with the same name as the required check. Selecting the final job(s) in workflows to be required for status checks, instead of selecting the full workflow, allows for a stand-in job with the same name to be used to satisfy the check. A stand-in workflow with a stand-in job, that has the same name as the final job in the original workflow, can be run.
This can be simplified further by having a single job at the end of each workflow that is fanned into.
- Easy to implement
- Prevents human error by being fully automated
- Stand-in job can use a smaller resource class than the normal jobs
- Stand-in workflow and job make it clear what is happening in both the UI and the CircleCI config
- Setup config can be locked down with config policies
- Requires a job to be spun up to satisfy the check
- Increases status check management overhead if workflow cannot be fanned back into a single or a small amount of jobs
Merging into the main branch requires the following status checks:
The CircleCI config uses the path filtering orb to set parameters to true if a change is made to any file within one of the three directories present. There is one parameter per directory.
A script is run after the parameters are set to check for any existing parameters. If any of the three parameters were not set to true then a stand-in parameter is set to true.
The downstream workflows are then triggered.
When files are changed within the directories, any parameters that were set to true run their normal workflows and the checks are satisfied. Below is a pull request showing a file being changed in each of the three directories, triggering their normal workflows and satisfying the checks.
Any parameters that were not set to true have a stand-in parameter set to true which triggers a stand-in workflow. The stand-in workflow contains a job with the same name as the required check, which satisfies it. Below is a pull request showing no files being changed, triggering stand-in workflows to satisfy the checks.
