이슈 보고

Tuist를 사용하다 보면 버그나 예상치 못한 동작을 마주칠 수 있습니다. 이런 경우 문제를 수정할 수 있도록 신고해 주시기 바랍니다.

GitHub 이슈는 저희의 티켓팅 플랫폼입니다#

이슈는 Slack이나 다른 플랫폼이 아닌 GitHub에서 GitHub 이슈로 보고해야 합니다. GitHub는 이슈를 추적하고 관리하기에 더 적합하며 코드베이스와 가까워 이슈 진행 상황을 파악하기 용이합니다. 또한 긴 형식의 문제 설명을 유도하여 보고자가 문제를 깊이 생각하고 더 많은 맥락을 제공하도록 돕습니다.

맥락은 매우 중요합니다#

충분한 맥락이 없는 이슈는 불완전하다고 판단되어 추가 맥락을 요청받게 됩니다. 제공되지 않으면 이슈는 종료됩니다. 이렇게 생각해 보세요: 제공하는 맥락이 많을수록 문제를 이해하고 해결하기가 더 쉬워집니다. 따라서 이슈가 해결되기를 원한다면 가능한 한 많은 맥락을 제공하세요. 다음 질문에 답해 보세요:

무엇을 하려고 했나요?
그래프 구조는 어떻게 되어 있나요?
사용 중인 Tuist 버전은 무엇인가요?
이 문제로 작업이 차단되고 있나요?

최소한의 재현 가능한 프로젝트를 제공해야 합니다.

새 Git 리포지토리를 만듭니다.
리포지토리 디렉터리에서 tuist init를 사용하여 프로젝트를 초기화합니다.
발생한 오류를 재현하는 데 필요한 코드를 추가합니다.
코드를 게시하고(GitHub 계정이 이에 적합합니다) 이슈를 생성할 때 해당 코드로 링크합니다.

재현 가능한 프로젝트의 이점#

범위 축소: 오류 외의 모든 요소를 제거하면 버그를 찾기 위해 깊이 파고들 필요가 없습니다.
비밀 코드 공개 불필요: 여러 이유로 메인 사이트를 공개하지 못할 수 있습니다. 일부만 재현 가능한 테스트 케이스로 다시 만들면 비밀 코드를 노출하지 않고도 문제를 공개적으로 시연할 수 있습니다.
버그 입증: 때로는 머신의 설정 조합으로 인해 버그가 발생하기도 합니다. 재현 가능한 테스트 케이스를 사용하면 기여자가 빌드를 다운로드하여 자신의 머신에서도 테스트할 수 있습니다. 이를 통해 문제 원인을 검증하고 좁힐 수 있습니다.
버그 수정 지원 받기: 다른 사람이 문제를 재현할 수 있다면 문제 해결 가능성이 높아집니다. 버그를 재현할 수 없다면 수정하는 것은 거의 불가능합니다.

이슈 보고

GitHub 이슈는 저희의 티켓팅 플랫폼입니다#

맥락은 매우 중요합니다#

재현 가능한 프로젝트#

재현 가능한 프로젝트란 무엇인가요?#

왜 재현 가능한 테스트 케이스를 만들어야 하나요?#

재현 가능한 프로젝트 생성 단계#

재현 가능한 프로젝트의 이점#