이슈 보고

튜이스트 사용자는 버그나 예기치 않은 동작을 발견할 수 있습니다. 발견한 경우 문제를 해결할 수 있도록 신고해 주시기 바랍니다.

깃허브 이슈는 티켓팅 플랫폼 {#github-issues-is-our-ticketing-platform}입니다.

이슈는 Slack이나 다른 플랫폼이 아닌 GitHub에서 GitHub 이슈로 보고해야 합니다. GitHub는 이슈를 추적하고 관리하는 데 더 적합하며 코드베이스에 더 가깝고 이슈의 진행 상황을 추적할 수 있습니다. 또한 문제에 대한 긴 형식의 설명을 장려하여 보고자가 문제에 대해 더 많이 생각하고 더 많은 맥락을 제공하도록 유도합니다.

컨텍스트가 중요합니다

충분한 맥락이 없는 이슈는 불완전한 것으로 간주되며 작성자에게 추가 맥락을 요청합니다. 컨텍스트가 제공되지 않으면 이슈가 닫힙니다. 더 많은 컨텍스트를 제공할수록 문제를 더 쉽게 이해하고 해결할 수 있습니다. 따라서 문제를 해결하려면 가능한 한 많은 전후 맥락을 제공하세요. 다음 질문에 답해 보세요:

• 무엇을 하려고 했나요?
• 그래프가 어떻게 보이나요?
• 어떤 버전의 Tuist를 사용 중이신가요?
• 이것이 당신을 차단하고 있나요?

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

재현 가능한 프로젝트

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

재현 가능한 프로젝트는 문제를 입증하기 위한 작은 Tuist 프로젝트로, 종종 이 문제는 Tuist의 버그로 인해 발생합니다. 재현 가능한 프로젝트에는 버그를 명확하게 입증하는 데 필요한 최소한의 기능이 포함되어야 합니다.

재현 가능한 테스트 케이스를 만들어야 하는 이유는 무엇인가요? 재현 가능한 테스트 케이스를 만들어야 하는 이유

재현 가능한 프로젝트를 통해 문제의 원인을 파악할 수 있으며, 이는 문제 해결을 위한 첫 번째 단계입니다! 버그 리포트에서 가장 중요한 부분은 버그를 재현하는 데 필요한 정확한 단계를 설명하는 것입니다.

재현 가능한 프로젝트는 버그를 유발하는 특정 환경을 공유할 수 있는 좋은 방법입니다. 재현 가능한 프로젝트는 여러분을 돕고자 하는 사람들을 도울 수 있는 가장 좋은 방법입니다.

재현 가능한 프로젝트를 만드는 단계

• 새 git 리포지토리를 만듭니다.
• 리포지토리 디렉터리에서 tuist init 을 사용하여 프로젝트를 초기화합니다.
• 표시된 오류를 다시 만드는 데 필요한 코드를 추가합니다.
• 코드를 게시한 다음(GitHub 계정이 이 작업을 하기에 좋은 곳입니다) 이슈를 만들 때 해당 코드에 연결합니다.

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

• 더 작은 표면적: 오류를 제외한 모든 것을 제거하면 버그를 찾기 위해 땅을 파헤칠 필요가 없습니다.
• 비밀 코드를 게시할 필요가 없습니다: 여러 가지 이유로 기본 사이트를 게시하지 못할 수도 있습니다. 일부만 재현 가능한 테스트 케이스로 다시 만들면 비밀 코드를 노출하지 않고도 문제를 공개적으로 시연할 수 있습니다.
• 버그의 증거: 때때로 버그는 머신의 설정 조합으로 인해 발생하는 경우가 있습니다. 재현 가능한 테스트 케이스를 사용하면 기여자가 빌드를 내려받아 자신의 컴퓨터에서도 테스트할 수 있습니다. 이를 통해 문제의 원인을 확인하고 범위를 좁히는 데 도움이 됩니다.
• 버그 해결에 도움을 요청하세요: 다른 사람이 문제를 재현할 수 있다면 문제를 해결할 가능성이 높은 경우가 많습니다. 먼저 버그를 재현할 수 없다면 버그를 고치는 것은 거의 불가능합니다.