Możliwości

Mechanizmy przygotowania projektu, środowiska wykonawczego i dalszej pracy nad PR-em.

Specyfikacja

Mechanizm	Działanie
Warm nodes	Wcześniej uruchomiony węzeł eliminuje tworzenie maszyny z czasu startu zadania. Przy włączonym prewarmingu i dostępnym warm node praca może ruszyć w kilka sekund. Warm node to nieużyta maszyna; po operacji jest usuwana i nie wraca do puli.
SOCI i wewnętrzny container registry	Obrazy środowiska AWE są publikowane z indeksami SOCI do wewnętrznego registry. Lazy loading pozwala uruchomić workera przed pobraniem całego obrazu; pozostałe dane obrazu są pobierane w tle.
Przygotowane środowisko projektu	AWE zawiera runtime projektu, zależności, narzędzia, konfigurację usług i instrukcje wykonania potrzebne do uruchamiania aplikacji oraz jej kontroli.
Osobny daemon Docker rootless	Docker działa na węźle poza kontenerem agenta, bez Docker-in-Docker wewnątrz workera. Daemon obsługuje budowanie obrazów i kontenery usług projektu, np. baz danych i kolejek. Daemon należy do stosu workera na jednorazowym węźle i nie jest współdzielony między zadaniami klientów.
Obrazy usług projektu	Środowisko deklaruje obrazy usług w prewarm_images i buildy z Dockerfile w source_builds. Obecny runtime pobiera lub buduje te obrazy na żądanie; wyprzedzający prewarming nie jest aktywny.
Ponowne użycie cache i refresh	Przygotowane zależności i generowane artefakty są używane ponownie. Refresh aktualizuje je lub unieważnia dla wybranej rewizji kodu. Ponowne użycie dotyczy cache zapisanych w obrazie projektu, bez przejmowania zmienionej przestrzeni roboczej zakończonego zadania.
Weryfikacja aplikacji	Buildy, testy jednostkowe i integracyjne działają w przygotowanym środowisku. Kontrole przez headless Playwright są dostępne, gdy projekt dostarcza przeglądarkę i jej zależności.
Dalsza praca nad pull requestem	Otwarte PR-y z etykietą zadania skonfigurowaną dla projektu kwalifikują się do automatycznej dalszej pracy, jeśli ich gałąź należy do podłączonego repozytorium. Aktualizacje PR-a, dyskusja, review, komentarze do kodu i zakończone kontrole CI mogą uruchomić agenta. Agent czyta bieżącą dyskusję, diff i wyniki kontroli, aby ustalić, czy potrzebne jest działanie.
Uwagi z review, CI i konflikty	Agent może uwzględniać uwagi wymagające działania, analizować błędy zadań CI i rozwiązywać konflikty merge. Uruchamia odpowiednie kontrole i publikuje gotowe zmiany na tej samej gałęzi PR-a, wraz z wynikami weryfikacji i pozostałymi problemami. Jeśli poprawki nie są potrzebne, pozostawia PR bez zmian i bez zbędnego komentarza.
Kontrola dalszej pracy i wykorzystanie kredytów	Automatyczne uruchomienia zużywają kredyty właściciela projektu. Powtórzone zdarzenia i zdarzenia otrzymane podczas oczekiwania, wykonania lub publikacji nie dodają kolejnego uruchomienia do kolejki. Agent odświeża stan PR-a przed zwróceniem wyniku; zatrzymuje się, jeśli PR został zamknięty, zmergowany lub stracił etykietę zadania. Po wyczerpaniu dostępnych kredytów nowe uruchomienia nie są zlecane. Ty decydujesz o merge’u.
Zoptymalizowany harness agenta	Harness dostrojony do pracy w AWE, z naciskiem na krótszy czas wykonania i mniejsze zużycie tokenów.