Designs in CI prüfen

Ein Design, das reiner Text ist, gehört in git, und ein Design in git kann bei jedem Push wie Code geprüft werden. agentee check beendet sich mit 0, wenn das Projekt sauber ist, mit 1, wenn es Fehler gibt, und mit 2, wenn eine Datei nicht geladen wird, sodass es direkt in CI passt.

#Der Prüfungsauftrag

name: check
on: [push, pull_request]

jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: curl -fsSL https://agentee.sh/install.sh | sh
      - run: echo "$HOME/.local/bin" >> "$GITHUB_PATH"
      - run: sudo apt-get install -y kicad-symbols kicad-footprints
      - run: agentee check hardware/

Die KiCad-Bibliotheken werden nur benötigt, wenn der Job Bauteile importiert; ein Projekt, das bereits seine Symbole und Footprints enthält, wird ohne sie geprüft. Weise check auf das Projektdirectory hin oder führe es von dort aus.

Fixiere die Version für reproduzierbare Ergebnisse, indem du von einem Release-Tag statt von der neuesten Version installierst:

      - run: curl -fsSL https://agentee.sh/install.sh | AGENTEE_VERSION=v0.1.0 sh

#Maschinenlesbare Ausgabe

agentee check --json

{
  "diagnostics": [
    {
      "at": "via [12.550, 11.000]",
      "file": "./lna.pcb.toml",
      "item": "lna",
      "message": "GND via sits in U1.2 0.175 mm from its edge, its 0.300 mm annulus reaches past the pad under the mask; centre it or use a smaller via",
      "rule": "via-annulus-past-pad",
      "severity": "warning"
    }
  ],
  "errors": 0,
  "ok": true,
  "warnings": 3
}

Jede Diagnose trägt ihre Datei, ihr Element, ihren Ort und ihren Schweregrad, und Layout-Diagnosen tragen ihre Regel-ID. Das reicht, um einen Pull Request zu annotieren, oder um in einem Projekt, das Warnungen als Fehler behandeln will, bei Warnungen zu scheitern. Eine Regel kann auch in der Platine selbst mit [drc] severity zu einem Fehler hochgestuft werden, was die Politik im Design statt im CI-Skript hält.

#Simulationen in CI

Die Prüfung führt nie eine Simulation aus. Jedes Ergebnis speichert einen Hash der Spezifikation, des Kupfers, das sie gesehen hat, und des Lagenaufbaus, und die Prüfung warnt, wenn sie nicht mehr übereinstimmen. Auf einem CI-Runner ohne GPU ist das der nützliche Teil: Ein Pull Request, der eine HF-Leiterbahn verschiebt, bekommt eine Veraltungs-Warnung auf dem FDTD-Ergebnis, und ein Interface, das dieses Ergebnis misst, schlägt sofort fehl.

DC-Abfall-, Wärme- und Logik-Simulationen sind billig genug, um in CI ausgeführt zu werden, wo der Runner eine GPU hat, und Logik-Simulationen brauchen gar keine:

      - run: agentee sim counter
        working-directory: hardware

Halte FDTD-Läufe auf einer Arbeitsstation und commite ihre Ergebnisse, damit CI das Design gegen die Simulationen prüft, die tatsächlich ausgeführt wurden.

#Rendern bei jedem Pull Request

      - run: |
          agentee render pcb:main -o main.png --canvas-only
          agentee render sch:main -o main-sch.png --canvas-only
        working-directory: hardware
      - uses: actions/upload-artifact@v4
        with:
          name: renders
          path: hardware/*.png

Das Rendern läuft headless, ohne Display oder GPU, sodass der Rezensent einer Hardware-Änderung die Platine sieht und nicht nur den Diff.

#Fertigungsdaten bei Release

on:
  push:
    tags: ["hw-v*"]

jobs:
  fab:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: curl -fsSL https://agentee.sh/install.sh | sh
      - run: echo "$HOME/.local/bin" >> "$GITHUB_PATH"
      - run: agentee fab pcb:main -o fab/
        working-directory: hardware
      - env:
          GH_TOKEN: ${{ github.token }}
        run: gh release create "$GITHUB_REF_NAME" hardware/fab/*.zip hardware/fab/*.csv hardware/fab/fab-notes.txt

fab lehnt ab, solange das Layout Fehler hat, sodass ein Tag auf einem kaputten Design fehlschlägt, statt Gerber zu versenden. Das Wasserzeichen im Bestückungsdruck trägt den Commit, aus dem das Paket gebaut wurde; ein Build aus einem Baum mit uncommitteten Änderungen sagt -dirty.