Bramka jakości (quality gate) to zestaw warunków, które musi spełnić nowy kod projektu PlusWorkflow, żeby analiza na serwerze dostała status „Passed”. Projekt używa bramki „Suncode way”. Bramka ocenia tylko nowy kod, więc dług techniczny w starszym kodzie jej nie blokuje — każda zmiana ma jednak spełniać progi.
| Warunek | Metryka w Sonarze | Próg | Wartość 14.11.2026 | Stan 14.11.2026 | Co mierzy |
|---|---|---|---|---|---|
| Pokrycie testami nowego kodu | new_coverage | co najmniej 40% | 32,9% | Niespełniony | Jaki procent linii i warunków w nowym kodzie wykonują testy jednostkowe. |
| Zduplikowane linie w nowym kodzie | new_duplicated_lines_density | najwyżej 3% | 1,7% | Spełniony | Jaki procent nowych linii jest kopią innego fragmentu kodu. |
| Przejrzane hotspoty bezpieczeństwa | new_security_hotspots_reviewed | 100% | brak hotspotów | Spełniony | Hotspot to miejsce wrażliwe pod względem bezpieczeństwa, które wymaga oceny człowieka (nie musi być błędem). Każdy w nowym kodzie musi mieć status Safe lub Fixed. |
| Ocena niezawodności | new_software_quality_reliability_rating | A | D | Niespełniony | Wynika z najpoważniejszego otwartego zgłoszenia wpływającego na niezawodność (błędy działania). |
| Ocena bezpieczeństwa | new_software_quality_security_rating | A | C | Niespełniony | Wynika z najpoważniejszego otwartego zgłoszenia wpływającego na bezpieczeństwo (podatności). |
| Ocena utrzymywalności | new_software_quality_maintainability_rating | A | A | Spełniony | Wynika z długu technicznego nowego kodu względem jego rozmiaru. |
Wszystkie warunki muszą być spełnione jednocześnie. Aktualne wartości są na stronie projektu w Sonarze; tabela pokazuje stan z dnia przygotowania tej strony.
Oceny niezawodności i bezpieczeństwa zależą od wagi najpoważniejszego otwartego zgłoszenia w nowym kodzie:
| Ocena | Najpoważniejsze otwarte zgłoszenie |
|---|---|
| A | brak zgłoszeń albo tylko o wadze Info |
| B | Low |
| C | Medium |
| D | High |
| E | Blocker |
Próg „A” oznacza, że jedno otwarte zgłoszenie o wadze Low w nowym kodzie wystarcza, żeby bramka nie przeszła. Zgłoszenia oznaczone jako False Positive albo Accepted nie liczą się do oceny (strona SonarQube - fałszywe alarmy i oznaczanie zgłoszeń). Ocena utrzymywalności liczy się inaczej: jako stosunek szacowanego czasu naprawy długu technicznego do szacowanego czasu napisania nowego kodu (A to najwyżej 5%).
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”, ustawienie 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.
Okres nowego kodu ustawia administrator Sonara. Gdy zostanie przesunięty (np. przy wydaniu wersji), zgłoszenia ze starszych zmian przestają liczyć się do bramki.
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.
Strona startowa projektu. Zakładka New Code (domyślna) pokazuje to, co decyduje o bramce:
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.
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.
Zakładka Issues z filtrami po lewej stronie. Żeby znaleźć zgłoszenia obniżające ocenę bramki, ustaw:
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.
Kliknięcie zgłoszenia otwiera panel szczegółów:
Web:S7930), linia (Line affected), szacowany czas naprawy (Effort) i kiedy zgłoszenie powstało (Introduced),
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łą.
Przycisk ze statusem (Open) otwiera menu:
Kiedy wybrać Accept, a kiedy False Positive, opisuje strona SonarQube - fałszywe alarmy i oznaczanie zgłoszeń. Po zmianie statusu dodaj komentarz z uzasadnieniem.
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.
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.
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.