Verificación de diseños en CI

Un diseño que es texto plano pertenece a git, y un diseño en git se puede comprobar en cada push como el código. agentee check termina con 0 cuando el proyecto está limpio, 1 cuando hay errores y 2 cuando un archivo no carga, así que encaja directamente en CI.

#El trabajo de verificación

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/

Las bibliotecas de KiCad solo se necesitan si el trabajo importa componentes; un proyecto que ya tiene sus símbolos y huellas se comprueba sin ellas. Apunta check al directorio del proyecto, o ejecútalo desde dentro.

Fija la versión para resultados reproducibles instalando desde una etiqueta de release en lugar de la última:

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

#Salida legible por máquina

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
}

Cada diagnóstico lleva su archivo, elemento, ubicación y severidad, y los diagnósticos de layout llevan su id de regla. Eso es suficiente para anotar una solicitud de extracción o para fallar por advertencias en un proyecto que quiera tratarlas como errores. Una regla también puede elevarse a error en la propia placa con [drc] severity, lo que mantiene la política en el diseño en lugar del script de CI.

#Simulaciones en CI

La verificación nunca ejecuta una simulación. Cada resultado registra un hash de la especificación, el cobre que vio y el apilamiento, y la verificación avisa cuando ya no coinciden. En un runner de CI sin GPU, esa es la parte útil: una solicitud de extracción que mueve una pista de RF recibe una advertencia de obsolescencia en el resultado FDTD, y una interfaz que mide ese resultado falla directamente.

Las simulaciones de caída DC, térmicas y lógicas son lo bastante baratas para ejecutarlas en CI donde el runner tiene una GPU, y las lógicas no necesitan ninguna:

      - run: agentee sim counter
        working-directory: hardware

Mantén las ejecuciones FDTD en una estación de trabajo y commita sus resultados, para que CI compruebe el diseño contra las simulaciones que se ejecutaron de verdad.

#Renderizados en cada 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

El renderizado se ejecuta en modo headless, sin pantalla ni GPU, para que quien revisa un cambio de hardware vea la placa además del diff.

#Paquetes de fabricación en 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 se niega mientras el layout tenga errores, por lo que una etiqueta en un diseño roto falla en lugar de enviar Gerbers. La marca de agua en la serigrafía lleva el commit desde el que se construyó el paquete; una construcción desde un árbol con cambios sin confirmar dice -dirty.