agentee

Produkcja

Sprawdzanie projektów w CI

Uruchamiaj agentee check przy każdym pushu, przerywaj build przy błędach, utrzymuj wyniki symulacji aktualne i dołączaj pakiet produkcyjny do wydania.

Projekt zapisany jako zwykły tekst należy do git, a projekt w git można sprawdzać przy każdym pushu jak kod. agentee check zwraca 0, gdy projekt jest czysty, 1, gdy są błędy, i 2, gdy plik się nie wczyta, więc wchodzi prosto w CI.

Zadanie sprawdzania

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/

Biblioteki KiCad są potrzebne tylko, jeśli zadanie importuje elementy; projekt, który już ma swoje symbole i footprints, sprawdza się bez nich. Wskaż check na katalog projektu albo uruchom go z jego wnętrza.

Zablokuj wersję dla odtwarzalnych wyników, instalując z tagu release, a nie najnowszej:

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

Wyjście maszynowo czytelne

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
}

Każdy diagnostyk niesie swój plik, element, miejsce i wagę, a diagnostyki projektu PCB nieszą identyfikator reguły. To wystarcza, by adnotować pull request albo zawieść na ostrzeżeniach w projekcie, który traktuje je jak błędy. Regułę można też podnieść do błędu w samej płytce przez [drc] severity, co trzyma politykę w projekcie, a nie w skrypcie CI.

Symulacje w CI

Sprawdzanie nigdy nie uruchamia symulacji. Każdy wynik zapisuje hash specyfikacji, miedzi, którą zobaczył, i stackupu, a sprawdzanie ostrzega, gdy już się nie zgadzają. Na runnerze CI bez GPU to jest użyteczna część: pull request, który przesuwa ścieżkę RF, otrzymuje ostrzeżenie o przestarzałym wyniku FDTD, a interfejs, który mierzy ten wynik, zawodzi od razu.

Symulacje spadku DC, termiczne i logiczne są na tyle tanie, by uruchamiać je w CI, gdzie runner ma GPU, a logiczne nie potrzebują żadnego:

      - run: agentee sim counter
        working-directory: hardware

Zostaw uruchamianie FDTD na stacji roboczej i commituj ich wyniki, by CI sprawdzał projekt względem symulacji, które faktycznie zostały uruchomione.

Renderowanie przy każdym 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

Renderowanie działa headless, bez wyświetlacza ani GPU, więc recenzent zmiany sprzętowej widzi płytkę, a nie tylko diff.

Pakiety fab przy 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 odmawia, gdy projekt PCB ma błędy, więc tag na zepsutym projekcie zawiedzie, zamiast wysyłać Gerbery. Wodny znak w opisach niesie commit, z którego zbudowano pakiet; build z drzewa z niezakommitowanymi zmianami mówi -dirty.

Popraw ten przewodnik · Markdown dla agentów