Ontwerpen controleren in CI

Een ontwerp in platte tekst hoort in git, en een ontwerp in git kan bij elke push worden gecontroleerd als code. agentee check eindigt met 0 als het project schoon is, met 1 als er fouten zijn en met 2 als een bestand niet laadt, dus het past direct in CI.

#De controletaak

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/

De KiCad-bibliotheken zijn alleen nodig als de job onderdelen importeert; een project dat al zijn symbolen en footprints heeft, wordt gecontroleerd zonder ze. Wijs check op de projectmap, of voer het daarbinnen uit.

Vergrendel de versie voor reproduceerbare resultaten door te installeren vanaf een release-tag in plaats van de nieuwste:

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

#Machineleesbare uitvoer

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
}

Elke diagnose bevat het bestand, het item, de plaats en de ernst, en layoutdiagnoses bevatten hun regel-id. Dat is genoeg om een pull request te annoteren, of om op waarschuwingen te falen in een project die ze als fouten wil behandelen. Een regel kan ook in de printplaat zelf verhoogd worden tot een fout met [drc] severity, wat het beleid in het ontwerp houdt in plaats van in het CI-script.

#Simulaties in CI

De controle voert nooit een simulatie uit. Elk resultaat registreert een hash van de specificatie, het kopervlak dat het zag en de stackup, en de controle waarschuwt als ze niet meer overeenkomen. Op een CI-runner zonder GPU is dat het nuttige deel: een pull request die een RF-spoor verplaatst, krijgt een verouderde waarschuwing op het FDTD-resultaat, en een interface die dat resultaat meet, faalt meteen.

DC-daling, thermische en logische simulaties zijn goedkoop genoeg om in CI uit te voeren waar de runner een GPU heeft, en logische simulaties hebben er helemaal geen nodig:

      - run: agentee sim counter
        working-directory: hardware

Houd FDTD-runs op een werkstation en commit hun resultaten, zodat CI het ontwerp controleert tegen de simulaties die daadwerkelijk zijn uitgevoerd.

#Renders bij elke 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

Rendering draait headless, zonder display of GPU, zodat de reviewer van een hardwarewijziging de printplaat ziet naast de diff.

#Fab-pakketten bij 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 weigert zolang het layout fouten heeft, dus een tag op een kapot ontwerp faalt in plaats van Gerbers te verzenden. De watermerk in de zeefdruk bevat de commit waaruit het pakket is gebouwd; een build uit een boom met niet-gecommitte wijzigingen zegt -dirty.