Verifica dei progetti in CI

Un design in testo semplice sta in git, e un design in git può essere verificato a ogni push come il codice. agentee check esce con 0 quando il progetto è pulito, 1 quando ci sono errori e 2 quando un file non si carica, così entra direttamente in CI.

#Il job di verifica

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/

Le librerie KiCad servono solo se il job importa componenti; un progetto che ha già i suoi simboli e footprint si verifica senza di esse. Punta check alla directory del progetto, o esegui da dentro.

Fissa la versione per risultati riproducibili installando da un tag di release invece che dall'ultima:

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

#Output leggibile da macchina

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
}

Ogni diagnostica porta il suo file, elemento, posizione e severità, e le diagnostiche di layout portano il loro id di regola. È abbastanza per annotare una pull request, o per fallire sugli avvisi in un progetto che vuole trattarli come errori. Una regola può anche essere alzata a errore nella scheda stessa con [drc] severity, che tiene la politica nel design invece che nello script di CI.

#Simulazioni in CI

La verifica non esegue mai una simulazione. Ogni risultato registra un hash della specifica, del rame visto e dello stackup, e la verifica avvisa quando non corrispondono più. Su un runner CI senza GPU questa è la parte utile: una pull request che sposta una pista RF riceve un avviso di obsolescenza sul risultato FDTD, e un'interfaccia che misura quel risultato fallisce del tutto.

Le simulazioni di caduta in corrente continua, termiche e logiche sono abbastanza economiche da eseguire in CI dove il runner ha una GPU, e le simulazioni logiche non ne richiedono affatto:

      - run: agentee sim counter
        working-directory: hardware

Tieni le esecuzioni FDTD su una workstation e committa i loro risultati, così CI verifica il design contro le simulazioni che sono state effettivamente eseguite.

#Render a ogni 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

Il rendering esegue in headless, senza display o GPU, così il revisore di un cambiamento hardware vede la scheda oltre che la diff.

#Pacchetti di produzione alla 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 rifiuta mentre il layout ha errori, così un tag su un design rotto fallisce invece di spedire Gerber. Il watermark nella serigrafia porta il commit da cui il pacchetto è stato costruito; una build da un albero con modifiche non committa dice -dirty.