CI/CD

Wszystkie testy, kompilacje i wydania Speedwave przechodzą przez GitHub Actions. Pliki workflow znajdziesz w .github/workflows/, a większość z nich przypina wywoływane akcje do konkretnego SHA commita, dodając w komentarzu numer wersji, na przykład actions/checkout@de0fac2e... # v6.0.2. Wyjątek stanowią dwa workflow Claude Code, bo zamiast tego korzystają z ruchomych tagów w rodzaju actions/checkout@v4.

Co uruchamia się przy każdym pushu i pull requeście

test.yml startuje przy pushu oraz przy pull requestach kierowanych do main lub dev i anuluje przy tym wcześniejsze, zastąpione przebiegi. Składa się z siedmiu zadań:

Zadanie	Runner	Co robi
lint	macos-latest	Rust clippy i sprawdzenie formatowania, Prettier, sprawdzenie typów TypeScript dla MCP, MCP ESLint
test	macos-latest	Testy Rust, testy transkrypcji, testy MCP z pomiarem pokrycia, testy Python dla MCP Office, testy bats dla entrypointu
desktop	macos-latest	Desktop clippy, Angular ESLint i testy z pomiarem pokrycia, testy konfiguracji Desktop i bramki wydania, testy kompilacji Tauri
audit	ubuntu-latest	npm audit dla serwerów MCP i aplikacji Desktop, cargo audit dla obu przestrzeni roboczych Rust
swift	macos-latest	Tylko pull requesty: buduje uniwersalne natywne binaria CLI dla macOS, a potem uruchamia testy Swift
runtime-windows	windows-latest	Testy Rust dla modułów Lima, WSL, kompilacji i job-object, a do tego sprawdzenie, że skrypty powłoki zachowują końce linii LF przy pobraniu kodu na Windows
desktop-windows-check	windows-latest	Kompiluje aplikację Desktop pod Windows, żeby wychwycić błędy występujące wyłącznie na tym systemie, bez tworzenia pełnego pakietu

Zadania przypisane wyłącznie do macOS działają tam dlatego, że część przestrzeni roboczej Rust kompiluje się jedynie na macOS i Windows. Co oznaczają liczby pokrycia i gdzie ustawia się progi, sprawdzisz w testowaniu.

Budowanie aplikacji Desktop

desktop-build.yml uruchamia się przy pull requestach oraz przy pushu do main i dev, ale tylko wtedy, gdy zmienią się istotne ścieżki: kod Desktop, crate’y Rust, serwery MCP, kontenery. Pull request buduje macOS wyłącznie na Apple Silicon, natomiast push obejmuje dodatkowo Intela i Windows. Bez klucza podpisującego, na przykład przy pull requeście z forka, dostajesz niepodpisany pakiet, a nie nieudaną kompilację.

Wydawanie

release-please.yml uruchamia się przy pushu do main i zarządza pull requestem wydania, jego podbiciem wersji oraz tagiem. Scalenie tego pull requesta uruchamia desktop-release.yml, który:

1. Sprawdza wersję i odnajduje pasujący szkic wydania.
2. Buduje i podpisuje aplikację Desktop dla macOS (obie architektury) oraz Windows, a następnie notaryzuje wersję dla macOS.
3. Kompiluje CLI między platformami dla macOS i Windows i dołącza archiwa do wydania.
4. Sprawdza, czy obecne są wszystkie oczekiwane pliki, a potem zmienia status wydania ze szkicu na opublikowany. Jeśli to końcowe sprawdzenie się nie powiedzie, wydanie wraca do szkicu.

Gdy brakuje sekretu podpisującego, dany krok zostaje pominięty, zamiast wywrócić cały workflow, a artefakt pozostaje niepodpisany lub bez notaryzacji. Pełny opis konfiguracji i tego, co trafia do wydania, znajdziesz w procesie wydawania.

Dwa kolejne workflow utrzymują pliki Cargo.lock i package-lock.json w aktualnym stanie na gałęziach wydania, a workflow backmerge po każdym wydaniu scala main z powrotem do dev: bezpośrednio albo przez pull request, gdy dev zdążył się rozejść z resztą.

Bramki wydania

Dwa workflow pilnują tego, co może trafić w stronę wydania, i napotkasz oba przy każdym pull requeście do main lub dev:

• pr-title.yml sprawdza, czy tytuł twojego pull requesta trzyma się formatu conventional commits.
• merge-strategy-check.yml uruchamia się przy pull requestach do main i wymaga tytułu w formacie conventional commit wyzwalającego wydanie, zanim pozwoli ci na squash-merge; wyjątkiem są automatyczne pull requesty wydania i backmerge.

Dzięki nim scalenie do main niezawodnie tworzy notatkę wydania i podbicie wersji, których oczekujesz. Jak tytuły commitów przekładają się na podbicia wersji, sprawdzisz w procesie wydawania.

Zależności i przegląd

Konfiguracja Dependabota zarządza aktualizacjami zależności, a towarzyszący jej workflow po każdym pushu do main wykonuje rebase otwartych pull requestów. W CI działają też dwa workflow Claude Code, oba ograniczone do stałej listy maintainerów: jeden odpowiada, gdy pull request, issue albo komentarz wspomina @claude, a drugi automatycznie recenzuje pull requesty w trybie tylko do odczytu.