이 문서는 SonarQube Issues 에 대한 정보를 공유하기 위해 작성되었다.
이슈에는 다음 세가지 유형이 있다.
이슈는 다음 다섯가지 심각도 중 하나를 가진다.
이상적으로 팀은 새로운 이슈(새로운 기술적 부채)를 도입(introduce)하지 않을 것이다.
SonarLint는 코드를 SCM으로 다시 Push 하기 전에 로컬 분석을 수행하여 취약 코드를 확인할 수 있고 이는 개발자를 도울 수 있다.
그러나 실제 업무에서 새로운 기술적 부채 없이 코딩 할 수있는 것은 아니며, 때로는 그것에 가치가 없다.
그래서 새로운 이슈가 도입된다(introduced).
때때로 이슈는 자명하다. 예를 들어 팀이 init-lower, camelCase 변수 명명 규칙에 동의하고 My_variable에서 이슈가 발생한 경우, 해당 문제를 이해하는 데 많은 문맥이 필요하지 않는다.
그러나 다른 상황에서는 이슈가 제기된 이유를 이해하는 데 문맥이 필수적일 수 있다. 이것이 SonarQube가 이슈 메시지가 표시되는 주요 이슈 위치뿐만 아니라 보조 이슈 위치도 지원하는 이유이다.
예를 들어 보조 이슈 위치는 메서드에 인지 복잡성(Cognitive Complexity)을 추가하는 메서드의 코드 조각을 표시하는 데 사용된다.
그러나 기여하는 위치의 간단한 세탁 목록이 이슈를 이해하기에 충분하지 않은 경우가 있는데, 예를 들어 코드를 통해 일부 경로에서 null 포인터를 역 참조 할 수있는 경우,
실제로 필요한 것은 이슈 흐름(issue flows)이다. 각 흐름은 이슈가 발생할 수 있는 코드를 통과하는 정확한 경로를 표시하도록 정렬된 보조 위치집합이다.
예를 들어 리소스가 해제되지 않은 코드를 통해 여러 경로가 있을 수 있기 때문에 SonarQube는 여러 흐름을 지원한다.
여러 위치의 이슈에 대한 자세한 내용은 
비디오 참고
검출된 Issue는 다음 5개의 상태 중 하나를 가진다.
Close된 Issue는 다음 해결 방법 중 하나를 가진다.
Resolve된 Issue는 다음 해결 방법 중 하나를 가진다.
다음과 같은 경우 Issue가 자동으로 Close된다. → (상태: Closed)
다음과 같은 경우 Issue가 자동으로 ReOpen된다. → (상태: Reopened)
이슈의 생성 날짜를 확인하기 위해 각 분석 중에 알고리즘을 실행하여 이슈가 새로운 이슈인지 또는 이전에 존재했는지 여부를 확인한다.
이 알고리즘은 이슈가 보고된 라인에 대한 콘텐츠 해시(공백 제외)에 의존한다. 여러 라인 이슈의 경우 첫 번째 라인의 해시가 사용된다.
각 파일에 대해(파일 이름 바꾸기 검색 후) 알고리즘은 이전 분석에서 이슈의 기본 목록을 가져와 이러한 이슈를 새 분석에서 보고한 원시 이슈 목록과 일치시키려고 시도한다.
알고리즘은 가장 강력한 증거를 사용하여 먼저 일치를 시도한 다음 약한 휴리스틱으로 되돌아간다.
일치하지 않는 "기본(base)" 이슈는 수정 된(Fixed) 것으로 Close된다.
일치하지 않는 "원시(raw)" 이슈는 새로운(New) 것이다.
위에서 설명한 것처럼 이슈가 "새로운" 것으로 결정되면 다음 질문은 이슈를 제공할 날짜다. 예를 들어 오랫동안 코드에 존재했지만 프로필에 새 규칙이 추가되었기 때문에 가장 최근의 분석에서만 발견된다면 어떻게 될까?
이 이슈에 해당 라인의 마지막 변경 날짜를 지정해야 할까, 아니면 처음 제기된 분석 날짜를 지정해야 할까? 즉, 소급되어야 할까?
라인에 대한 마지막 변경 날짜를 사용할 수 있는 경우(SCM 통합 필요) 특정 상황에서 이슈는 소급된다.
결과적으로, 백데이트가 새로 제기 된 이슈를 새 코드에서 제외시킬 가능성이 있다.
Committer가 SonarQube 사용자와 상호 연관될 수 있는 경우, 분석 중에 이슈 라인의 마지막 Committer에 새 이슈가 자동으로 할당된다.
참고로 현재 파일 위의 모든 레벨의 이슈(예: Directory/Project)는 자동으로 할당될 수 없다.
로그인 및 이메일 상관 관계는 자동으로 이루어진다. 예를 들어 사용자가 이메일 주소로 커밋하고 해당 이메일 주소가 SonarQube 프로필의 일부인 경우,
사용자가 마지막 Committer였던 라인에서 발생한 새로운 이슈가 사용자에게 자동으로 할당된다.
추가 상관 관계는 사용자 프로필에서 수동으로 수행할 수 있다.
이슈와 연결된 SCM 로그인이 이슈 작성자(Issue author)에게 허용되는 255자를 초과하는 경우, 작성자(Author)는 공백으로 처리된다.
SonarQube의 이슈 워크플로우(Issues workflow)는 이슈를 관리하는 데 도움이 될 수 있다. 이슈에 대해 수행할 수 있는 일곱 가지 작업(코드에서 수정하는 것 외에)은
주석 달기(Comment), 할당(Assign), 확인(Confirm), 심각도 변경(Change Severity), 해결(Resolve), 수정하지 않음(Won't Fix) 및 거짓 긍정(False Positive)이다.
이러한 작업은 세 가지 범주로 나눌 수 있다.
첫 번째는 "기술 검토(Technical review)" 범주다.
확인(Confirm), 거짓 긍정(False Positive), 수정하지 않음(Won't Fix), 심각도 변경(Severity change) 및 해결(Resolve) 작업은 모두 이 범주에 속하며,
이슈의 유효성을 확인하기 위해 이슈를 초기 검토(Initial review)한다고 가정한다.
마지막 검토 기간(하루, 일주일 또는 전체 스프린트)에 추가 된 기술 부채(Technical debt)를 검토할 시간(Time to review)이라고 가정한다. 각각의 새로운 이슈를 살펴보고 다음을 수행한다.
많은 이슈를 거짓 긍정(False Positive) 또는 수정하지 않음(Won't Fix)으로 표시하는 경향이 있다면, 일부 코딩 규칙이 문맥에 적합하지 않다는 것을 의미한다.
따라서 품질 프로필(Quality Profile)에서 완전히 비활성화하거나 이슈 제외를 사용하여 애플리케이션의 특정 부분(또는 개체 유형)에 사용되지 않도록 규칙의 초점을 좁힐 수 있다.
마찬가지로 심각도를 자주 변경할 경우, 프로필에서 규칙 심각도를 업데이트하는 것을 고려하라는 메시지가 표시된다.
이슈를 편집하면 관련 메트릭(예: 신규 버그)이 자동으로 업데이트되며, 관련된 경우 품질 게이트(Quality Gate) 상태도 자동으로 업데이트된다.
일단 이슈가 기술적 검토(Technical review)를 거치면 누가 이슈를 처리 할 것인지 결정할 시간이 온다. 기본적으로 이슈가 발생할 때 이슈 라인의 마지막 Committer에 할당되지만,
자신이나 다른 사람에게 다시 할당할 수 있다. 알림을 등록한 경우 할당된 사용자는 할당 받은 이슈에 대한 메일 알림을 받게 되며,
내 계정 공간의 내 이슈 목록을 포함하여 이슈가 표시되는 모든 곳에 할당된 사용자가 표시된다.
이슈의 수명 주기 동안 언제든지 이슈에 대한 설명을 기록할 수 있다. 댓글(Comment)은 실행 중인 로그의 문제 세부 정보에 표시된다. 작성한 댓글(Comment)을 편집하거나 삭제할 수 있다.
이슈의 태그를 편집할 수 있다. 이슈는 해당 태그를 만든 규칙의 태그를 상속하지만, 문제에 설정된 태그는 완전히 편집할 수 있다.
태그는 프로젝트에 대한 찾아보기 권한(Browse permissio)이 있는 사용자에 대해 마음대로 생성, 추가 및 제거할 수 있다.
처음에는 관련 규칙에서 상속되지만 이슈에 대한 태그는 규칙과 동기화되지 않으므로 이슈에 태그를 추가해도 해당 태그가 규칙의 이슈에 추가되지는 않습니다.
이러한 모든 변경 사항은 이슈 검색 결과 창의 대량 변경(Bulk Change) 옵션을 사용하여 한 번에 여러 이슈에 대해 수행할 수 있다.
기본적으로 Close된 이슈는 30일 동안 유지된다. 자세한 내용은 하우스 키핑을 참조.