Support multiple files in .circleci folder
under review
A
Aaron Taylor
We are migrating to a mono-repo setup for a number of previously separate codebases, and our CircleCI config file has grown to many hundreds of lines. Now that config is within a
.circleci/
directory, is there an opportunity to split up the config file into multiple pieces to make it more comprehensible?There was a similar feature request files here previously: https://discuss.circleci.com/t/support-multiple-files-in-circleci-folder/18705
CCI-I-246
S
Sebastian Lerner
https://circleci.com/changelog/configuration-sources-can-be-used-to-create-github-app-triggers-in-project/
This is now possible for orgs that integrate with our GitHub App integration (https://circleci.com/docs/github-apps-integration/). Reach out to sebastian@circleci.com for any questions/feedback. We'll be updating docs soon.
https://discuss.circleci.com/t/product-update-multiple-configuration-files-per-project/50637
B
Brandon Doyle
I've written the following to assist with this, based on some work CircleCI did.
Kinda combines their path-filtering orb and continuation orb into one and lets you write <module>.ignore-files with .gitignore-like syntax under .circleci/ as well, to avoid running a workflow if things like, say, a markdown file has changed in a terraform directory, etc.
B
Brandon Doyle
Brandon Doyle: orb that I'm still maintaining ~ https://github.com/bjd2385/dynamic-continuation-orb
F
Fulton Byrne
Gitlab has the notion of "includes" which can "include" configuration from anywhere even a URL!
Salil Subbakrishna
under review
It's possible to dynamically select and combine config files using dynamic config (https://circleci.com/docs/2.0/dynamic-config/) We're looking into packaging this into an orb but in the meantime it is now possible to use dynamic config to combine multiple smaller config files into a single config to be used in the pipeline.
Mikhail Tymchuk
Salil Subbakrishna: This is all too complex. I see at as an config.yml file with all workflows defined in there + a bunch of job import commands which are defined in other files. Jobs can be defined in the same config.yml file as usual.
R
Roopak Venkatakrishnan
I recently wrote about an easy way to split your yml file here: https://blog.roopakv.com/breaking-up-circleci-yml/
A
Agam More
I'm currently doing this with the following structure and script (doesn't allow aliases atm):.circleci/ ci/ commands/ jobs/ main.yml#!/usr/bin/env bashecho "Packing all YAML files..." && \ circleci config pack ./.circleci/ci > ./.circleci/config.yml && \ echo "Done packing." && echo "Validating compiled config.yml" && circleci config validate
B
Brian Beck
Just noticed this related idea: https://ideas.circleci.com/ideas/CCI-I-208
B
Brian Beck
We often will have application code and library code in the same repo. It would be nice to be able to treat these as different workflows in CircleCI. I we commit a change in the library code it would trigger the library workflow and if we commit a change in the application code it would trigger the application workflow. As it is now, we have to separate them into different repositories.
A
Amram Ben David
I would like this feature as well
I
Ian Rose
> How about orbs instead?
Being able to simply #include another file (or similar) is miles simpler than using Orbs. I want to empower everyone on our engineering team to make changes to the build as necessary, but I definitely don't want everyone to have to learn how to interact with Orbs. Most people just need to make a relatively small change to a shell command in our config.
Load More
→