Spaces:
Running
Stabilizacja CI/CD i Autofix - GrantForge AI
Zaproponowane przez Ciebie zalecenia to doskonały plan ratunkowy (tzw. "firefighting plan"), aby przywrócić stabilność w procesie wytwarzania oprogramowania oraz ulepszyć najbardziej awaryjny punkt systemu — Autofix.
Proposed Changes
Poniżej znajduje się szczegółowy plan implementacji Kroków 1 i 2, od razu w tej iteracji.
1. Pre-commit Hooks & Local Checks
Wprowadzimy blokadę błędnych pushy poprzez narzędzie pre-commit. Pozwoli to na lokalne wyłapywanie błędów lintingu i testów przed wypchnięciem kodu na serwer.
[NEW] .pre-commit-config.yaml
- Konfiguracja hooków do
ruff(linter i formatter) orazpytest(uruchomienie szybkich testów backendowych przed pushem). - Dodanie instrukcji w README, jak wykonać
pip install pre-commit && pre-commit install -t pre-push.
[NEW] scripts/pre_push_tests.sh
- Prosty skrypt bashowy odpalany przez
pre-commit(hook typu pre-push), który uruchomipytest tests/wewnątrz katalogubackend. W razie błędu —git pushzostanie zablokowany.
2. Autofix Resilience: Backoff, Retry & Fuzzy Matching
Obecnie funkcja autofix przekazuje wszystkie błędy audytu do modelu przy poprawianiu każdej sekcji osobno, co wywołuje halucynacje LLM. Co więcej, wywołania z Frontendu padają z błędem 429 (Rate Limit).
[MODIFY] backend/endpoints/projects.py
- Fuzzy Matching Issues: Dodanie logiki filtrowania
audit_data["issues"]. Zamiast przesyłać wszystkie błędy, użyjemySequenceMatcherz bibliotekidifflib, aby dopasowaćissue['affected_section']dosection_t(z progiem podobieństwa np. 0.6) oraz dołączyć błędy oznaczone jako "Ogólne". To znacznie poprawi kontekst dla LLM. - Backend Retries: Dodanie
.with_retry(stop_after_attempt=3, wait_exponential_jitter=True)(lub wbudowanego w klasę modelumax_retries) na poziomie łańcucha Langchain (chain.invoke), co ukryje błędy 429 z API Google.
[MODIFY] frontend-react/src/components/project/ProjectAuditPanel.tsx
- Frontend Retry & Backoff Loop: Ulepszenie pętli
forwywołującej autofix. Przy napotkaniustatus === 429, zamiast natychmiast przerywać i zwracać błąd, system poczeka np. 15-20 sekund i spróbuje ponownie, powiadamiając użytkownika toastem "Oczekiwanie na reset limitów AI...".
3. Wprowadzenie Staging Branch & Zmiany w CI/CD
Aby powstrzymać łamanie gałęzi main, wdrożymy model staging -> main.
[MODIFY] .github/workflows/ci.yml
- Podział ról:
pushnastaging: Uruchamia pełny pipeline (Lint, Testy, Build) — bez publikacji na główny Render (zablokowany webhook).pushnamain: Wykonywany tylko przy poprawnym PR zestaging. Obejmuje Deploy do Render.com.
- Uproszczenie: Rozdzielenie zadań i upewnienie się, że
deepevalnie blokuje wdrożeń (już macontinue-on-error, ale potwierdzimy jego poprawność).
User Review Required
Polityka Staging: Po zmianie
ci.ymlwymusimy, że bieżący development będzie odbywał się na gałęzistaging. Będziesz musiał tworzyć lokalne commity nastaging, a namainprzenosić kod przez PR na GitHubie. Czy zgadzasz się na zmianę Twojego workflow w Git, w którymmainstanie się "świętą" gałęzią tylko dla działających wydań, a Ty będziesz pracował nastaging?
Open Questions
- Staging Environment on Render: Czy posiadasz już przygotowany darmowy Web Service na platformie Render pod "Staging", czy mam w
ci.ymlpominąć automatyczny deploy zestagingdo czasu ręcznego utworzenia tego środowiska przez Ciebie? - Pre-commit: Uruchomienie pre-commit będzie wymagało od Ciebie lokalnego uruchomienia
pre-commit install. Czy wolisz, abym stworzył prosty skrypt.bat/bash, który to zautomatyzuje podczas startu?
Verification Plan
- Ręczne wywołanie autofixu: Weryfikacja logów backendu, aby upewnić się, że po wdrożeniu poprawek do
projects.py, do LLM wysyłane są tylko filtrowane issues pasujące do sekcji. - Zasymulowanie 429 (Rate Limit): Wywołanie autofixu na wszystkich sekcjach pod rząd (bez przerw). Upewnienie się, że frontendowy backoff radzi sobie z zawieszeniem i wznawia proces.
- Instalacja hooków: Odpalenie próbnego złego commita i upewnienie się, że hook
pre-pushlubpre-commitgo odrzuci.