If you’re still experiencing the pain of config.yml copypasta even after using orbs, here’s a possible next step in your evolution.
2 Likes
How would your strategy be different for a monorepo? What do you think about breaking up files into mutiple configs (like in Breaking up your CircleCI yaml into multiple files | Reflections) and using dynamic config to recombine them?
Great question, @Cedric! I’ve been thinking about this too and what I’ve though of so far is to have a top-level .circleci/config.yml that declares a setup_xxxx job for each subproject/microservice. If there is a need to create resources shared across subprojects, there could also be a setup_shared_resources job in there.
Of course, each of those setup_xxx jobs should be smart enough to NOT run their subproject’s pipeline if the change doesn’t concern them.
Alternatively, you could extract the subproject setup_xxx jobs and put them in the subproject’s own .circle/config.yml file as you suggested.
This make command could be automated with continuations, so there’s no need for all the extra work on the development/developers’ side.
Bit of a similar side project I’ve been working on (and currently in-use at my organization), is dynamic continuation, which breaks up configs into workflows that target top-level directory code changes (so if code in a directory changes, its associated work flow is ran, otherwise ignored).
This make command could be automated with continuations, so there’s no need for all the extra work on the development/developers’ side.
Hi @bjd2385. Which make command are you referring to?
I think I was referring to the make command mentioned in the article linked above