...
Nowy kod to linie dodane lub zmienione od analizy bazowej z 16.10.2026. Serwer ma tak ustawiony okres nowego kodu dla gałęzi main (tryb „konkretna analiza”, ustawiony ręcznie 14.11ustawienie zmienione 16.10.2026). Wszystko, co zmieniło się w kodzie od tej daty, liczy się do bramki — także linie tylko przeformatowane albo przeniesione, np. przy migracji JSP ze Struts na Spring.
...
- Zgłoszenia: poprawiaj uwagi wtyczki w IDE i asystenta AI na zmienionych liniach przed MR-em (SonarQube - Connected Mode w IntelliJ, SonarQube - praca z asystentem AI). Każde zgłoszenie wpływające na niezawodność lub bezpieczeństwo obniża ocenę poniżej A.
- Pokrycie: pisz testy jednostkowe do nowej logiki. Próg 40% dotyczy całego nowego kodu w okresie, więc kod bez testów obniża wynik całego zespołu.
- Duplikacja: nie kopiuj większych fragmentów kodu; wydziel wspólną część.
- Fałszywe alarmy: oznaczaj je na serwerze z uzasadnieniem po scaleniu, nie ukrywaj w kodzie.
Analiza raportu w interfejsie Sonara
Raport projektu jest pod adresem https://sonar.suncode.local/dashboard?id=PlusWorkflow (wymaga zalogowania). Zrzuty pochodzą z 14.11.2026 — wartości na nich są przykładowe.
1. Overview — stan bramki
Strona startowa projektu. Zakładka New Code (domyślna) pokazuje to, co decyduje o bramce:
- Quality gate — wynik ostatniej analizy: Passed albo Failed.
- New Code Since … — od kiedy liczy się nowy kod (tu od 16.10.2026).
- N conditions failed — lista niespełnionych warunków z wartością i progiem. Każdy jest klikalny i prowadzi do szczegółów.
- Kafelki po prawej (New issues, Coverage, Duplications, Security Hotspots) — metryki nowego kodu. Kafelek z etykietą Failed to warunek, który nie przechodzi.
2. Overall Code — cały kod
Zakładka Overall Code pokazuje stan całego projektu, razem z kodem sprzed okresu nowego kodu. Bramki nie blokuje — oceny E i niskie pokrycie wynikają tu z długu technicznego w starym kodzie. Przydaje się do planowania porządków, nie do oceny bieżących zmian.
Na dole strony jest stała informacja Limited security analysis: nasza wersja SonarQube Community Build nie wykrywa podatności typu wstrzyknięcie (SQL injection, XSS). Brak takich zgłoszeń w Sonarze nie oznacza, że ich w kodzie nie ma.
3. Ostrzeżenia analizy
Komunikat The last analysis has warnings → See details pokazuje problemy samej analizy, nie kodu. Obecnie jest to ostrzeżenie o kodowaniu znaków w części plików źródłowych — szczegóły są w logach skanera w zadaniu CI, które uruchamia analizę. Pliki, których skaner nie odczytał poprawnie, mogą mieć niepełne wyniki.
4. Issues — które zgłoszenia psują bramkę
Zakładka Issues z filtrami po lewej stronie. Żeby znaleźć zgłoszenia obniżające ocenę bramki, ustaw:
- New code — tylko nowy kod,
- Software Quality — Reliability albo Security (ocena, która nie przechodzi),
- Severity — od najwyższej wagi, bo ocena wynika z najpoważniejszego zgłoszenia (strona o ocenach A–E wyżej),
- Issue status — Open i Confirmed.
Lista jest pogrupowana według plików. Przydatne są też filtry Author (autor zmiany według git blame) i Rule. Link z ustawionymi filtrami można skopiować i wkleić do zgłoszenia w Jirze.
5. Szczegóły zgłoszenia
Kliknięcie zgłoszenia otwiera panel szczegółów:
- nazwa reguły z kluczem (np.
Web:S7930), linia (Line affected), szacowany czas naprawy (Effort) i kiedy zgłoszenie powstało (Introduced), - po prawej Software qualities impacted — na którą ocenę wpływa i z jaką wagą,
- zakładka Where is the issue? — fragment kodu z zaznaczonym miejscem.
Zakładka Why is this an issue? wyjaśnia regułę i jej skutki, a How can I fix it? pokazuje przykłady poprawki. Zanim uznasz zgłoszenie za fałszywy alarm, przeczytaj opis reguły — często wymienia sytuacje, w których kod jest zgodny z regułą.
6. Zmiana statusu
Przycisk ze statusem (Open) otwiera menu:
- Accept — problem jest prawdziwy, ale świadomie go nie poprawiamy. Przestaje wpływać na bramkę.
- False Positive — reguła się myli. Przestaje wpływać na bramkę.
- Confirm — problem potwierdzony, nadal wpływa na bramkę.
Kiedy wybrać Accept, a kiedy False Positive, opisuje strona SonarQube - fałszywe alarmy i oznaczanie zgłoszeń. Po zmianie statusu dodaj komentarz z uzasadnieniem.
7. Activity zgłoszenia — kto i dlaczego zmienił status
Zakładka Activity w szczegółach zgłoszenia pokazuje historię zmian statusu i komentarze. Tu sprawdzisz, kto oznaczył zgłoszenie i z jakim uzasadnieniem. Komentarze obsługują ograniczony Markdown — unikaj znaku = na początku zdania i odwrotnych apostrofów, bo psują formatowanie.
8. Pokrycie testami nowego kodu
Reporting → Measures → Coverage → Uncovered Lines z widokiem listy (lub kliknięcie warunku pokrycia na Overview). Pliki są posortowane według liczby niepokrytych linii w nowym kodzie, więc od góry widać, gdzie dopisanie testów najbardziej podniesie wynik.
Po kliknięciu pliku Sonar pokazuje kod z oznaczeniami na marginesie: czerwony pasek to linia niepokryta testami, zielony — pokryta, żółty — warunek pokryty tylko częściowo. Linie należące do nowego kodu są wyróżnione tłem, a najechanie na znacznik pokazuje etykiety Uncovered code i New Code. Plik na zrzucie nie ma żadnych testów (pokrycie 0%), dlatego widać tylko czerwone znaczniki.
9. Activity projektu — historia analiz
Reporting → Activity pokazuje historię analiz z wykresem (liczba zgłoszeń, pokrycie, duplikacje) i zdarzeniami. Filtr Events filter → Quality gate zostawia tylko zmiany stanu bramki, co pomaga ustalić, od której analizy bramka nie przechodzi.
Strona Quality gate history w tym samym menu jest u nas pusta: działa tylko przy okresie nowego kodu ustawionym na „Previous version”, a my używamy konkretnej analizy bazowej.