In traditional hardware teams, generating manufacturing release packages is an exhausting, manual routine: open Pcbnew, plot Gerbers, drill holes, export STEP models, print schematic PDFs, generate CSV pick-and-place files, take viewport screenshots for the assembly guide, and zip them into an archive.

If an engineer fixes a typo in a resistor label at 5:00 PM on Friday, the entire 45-minute export cycle must be repeated from scratch. Humans make mistakes under pressure: forgetting to regenerate drill files or shipping mismatched BOMs.

Using KiBot inside a structured Git CI/CD workflow, every git push can automatically build, validate, and publish complete fabrication and assembly packages.

Here is an architectural walkthrough of our standard KiCad CI/CD project template (KDT_Hierarchical_KiBot).

1. The CI/CD Pipeline Architecture

[ Engineer commits layout changes to Git ]
                     │
                     ▼
             [ git push origin ]
                     │
                     ▼
  GitHub Actions / GitLab CI Runner (KiBot Container)
                     │
                     ├─► Step 1: ERC & DRC Gates (Fail build if violations exist)
                     ├─► Step 2: Fabrication Drawing PDF (Stackup, Drill table, Notes)
                     ├─► Step 3: Assembly Drawing PDF (Top/Bottom, DNP crosses, Tables)
                     ├─► Step 4: 3D Photorealistic Renders (Top, Bottom, Isometric)
                     ├─► Step 5: Interactive HTML BOM & Cost Matrix (KiCost)
                     ├─► Step 6: Visual Git Diffs (Schematic & Layout change viewer)
                     └─► Step 7: Automated Release Package ZIP & Documentation Portal

2. Automated Fabrication & Assembly Drawings

The most time-consuming task for PCB engineers is drafting mechanical drawings for fabrication and assembly houses. KiBot automates these documents directly into multi-page vector PDFs:

+─────────────────────────────────────────────────────────────+
|  PROJECT TITLE BLOCK (Automated Date, Hash & Rev)           |
+─────────────────────────────────────────────────────────────+
|                                                             |
|   [ Layer Stackup Table ]          [ Drill Size Table ]     |
|   Layer 1: Top Copper (0.035mm)    Ø0.30mm (142 Vias, PTH)  |
|   Dielectric: FR4 (0.100mm)        Ø0.90mm (8 Pins, PTH)    |
|   Layer 2: In1.Cu GND Plane        Ø1.20mm (4 Holes, NPTH)  |
|                                                             |
+─────────────────────────────────────────────────────────────+
|   [ Fabrication Notes ]                                     |
|   1. Board thickness: 1.6mm +/- 10%                         |
|   2. Surface Finish: ENIG (Au: 0.05um, Ni: 3-5um)           |
|   3. Impedance control: +/- 10% on 50R single-ended traces  |
+─────────────────────────────────────────────────────────────+

Automated DNP (Do Not Populate) Crosses

When assembling variations of a board (e.g. testing different motor drivers or excluding optional debug circuitry), components marked as DNP or EXCLUDE_FROM_BOM in the schematic are automatically drawn with visible diagonal red crosses on the assembly drawing, preventing manufacturing line confusion.

3. Visual Git Diffs: Reviewing Hardware Changes Like Code

Reviewing a raw Git diff of a 100,000-line .kicad_pcb or .kicad_sch file in a pull request is impossible for human reviewers.

The CI pipeline runs a visual diff engine on every branch:

  1. Renders the schematic sheets and PCB layers of the main branch into SVG.
  2. Renders the incoming branch into SVG.
  3. Generates an interactive web view where added traces are colored green, deleted traces are colored red, and moved components flash between revisions.

This turns hardware pull requests into clear, visual design reviews.

4. Synchronized Revision History & CHANGELOG.md

A common source of confusion in hardware production is a mismatch between the project’s root CHANGELOG.md and the schematic title block:

  • In our template, the schematic’s Revision History Sheet is linked to Git tags and commit messages.
  • The CI pipeline verifies that semantic version bumps (v1.2.0) correspond to documented entries in CHANGELOG.md, automatically stamping the release date, Git SHA-1 hash, and author onto the schematic title blocks.

5. Local Execution: No Cloud Dependency

While the pipeline runs on GitHub Actions and GitLab CI runners, engineers can execute the entire generation locally with a single script:

./kibot_launch.sh

Or on Windows:

docker run --rm -v ${PWD}:/kicad -w /kicad setsoft/kibot:latest kibot

In under 90 seconds, all fabrication archives, STEP 3D models, bill-of-materials spreadsheets, and interactive visual documentation are generated in a clean Output/ folder ready for ordering.