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 shWyjś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: hardwareZostaw 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/*.pngRenderowanie 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.txtfab 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.