I've ripped out chunks of KiCad to run as CI/CD on the basic PCBs I have. KiCad's data and code is really not geared up for this, so quite a bit had to be hacked up to make it idempotent and even just to bring it up to basic C++ coding standards.
I've been looking at upstreaming what I can and what would even make sense. Ultimately I've switched to mostly using non-KiCad python (dealing with the messy nature of the bundled python wasted 3 solid days, don't use it unless you must) to generate and manage a parts DB + vector drawings that are then processed into the KiCad formats.
It works, but a lot of KiCad internals were simply never designed to handle this scenario. Even multiple PCBs are a pain. It uses multiple proprietary vector representations, some for rendering and some for analysis, etc. The file formats themselves are ok to deal with but aren't well-specified so they will change on you.
Fortunately, the end Gerbers are well defined and it's often easier to simply generate those directly vs going through KiCad if the DRC are guaranteed by construction to never be violated
I've been looking at upstreaming what I can and what would even make sense. Ultimately I've switched to mostly using non-KiCad python (dealing with the messy nature of the bundled python wasted 3 solid days, don't use it unless you must) to generate and manage a parts DB + vector drawings that are then processed into the KiCad formats.
It works, but a lot of KiCad internals were simply never designed to handle this scenario. Even multiple PCBs are a pain. It uses multiple proprietary vector representations, some for rendering and some for analysis, etc. The file formats themselves are ok to deal with but aren't well-specified so they will change on you.
Fortunately, the end Gerbers are well defined and it's often easier to simply generate those directly vs going through KiCad if the DRC are guaranteed by construction to never be violated