An automated release job must distinguish running a rule checker successfully from finding no blocking design violations. A process can finish normally while producing a report that contains errors. Define the pipeline’s decision using the checker’s documented behavior and the project’s accepted severity policy.
Capture the exact invocation
KiCad 9’s CLI manual documents an option that makes DRC violations affect the process exit code. Save the complete command, software version, input identity, and selected severity options in the release record. A script name by itself does not reveal what was checked.
Decide how warnings and approved exclusions are treated. A project may require some warnings to block release while retaining accepted exclusions for review. Express that policy deliberately instead of inheriting a tool default that could change between workstations or software versions.
Verify the gate with known cases
| Controlled input | Expected pipeline behavior |
|---|---|
| Reviewed clean example | Produce a current report and satisfy the defined gate. |
| Example containing a known blocking violation | Stop the release and retain the violation evidence. |
| Unreadable input or tool failure | Report execution failure without claiming a clean check. |
| Accepted exclusion | Follow the explicit exclusion policy and preserve its visibility. |
Use a controlled test fixture or disposable project copy for these checks, keeping intentional defects out of released designs. The goal is to validate the automation’s decision, not to rerun the entire PCB qualification program. Review which rules actually execute separately.
Check the artifact as well as the status
For example, a wrapper may ignore the checker’s nonzero status because a later file-copy command succeeds. Another script may reuse yesterday’s report when the new command fails before writing a file. Require a report associated with the current input and invocation, and propagate the actual checking result through the wrapper.
Use the stale-output review when packaging the evidence. Keep execution failure, design violations, and policy-approved exclusions distinguishable in the final job summary.
Revalidate the gate after changing command options, wrapper logic, or the installed EDA version. Keep the known-case results beside the script revision. A green automation status is trustworthy only when its tested meaning matches the release policy the engineering team intended.
Move from reading to a build-ready project
Use the fabrication and assembly checklists to prepare drawings, production files and test requirements.
Open the DFM checklist