コンテンツへスキップ

問題の報告

Tuist の使用中にバグや予期しない動作に遭遇することがあります。その場合は、修正できるよう報告してください。

GitHub Issues をチケット管理プラットフォームとして利用しています#

問題は Slack や他のプラットフォームではなく、GitHub issues として GitHub で報告してください。GitHub は問題の追跡と管理に適しており、コードベースに近く、進捗を追跡できます。また、問題の詳細な説明を促すため、報告者が問題を整理し、より多くのコンテキストを提供しやすくなります。

コンテキストが重要です#

コンテキストが不十分な問題は不完全と判断され、追加のコンテキストを求められます。提供されない場合、問題はクローズされます。コンテキストを多く提供するほど、問題の理解と修正が容易になります。問題の修正を希望する場合は、可能な限り多くのコンテキストを提供してください。以下の質問に答えてみてください。

  • 何をしようとしていましたか?
  • グラフはどのような構造ですか?
  • 使用している Tuist のバージョンは何ですか?
  • この問題は作業をブロックしていますか?

最小限の再現プロジェクトの提供も必須です。

再現プロジェクト#

再現プロジェクトとは何ですか?#

再現プロジェクトは、問題を提示するための小さな Tuist プロジェクトです。多くの場合、この問題は Tuist のバグによって引き起こされます。再現プロジェクトには、バグを明確に示すために必要な最低限の機能のみを含めるべきです。

なぜ再現テストケースを作成すべきですか?#

再現プロジェクトにより、問題の原因を特定でき、修正への第一歩となります!バグ報告で最も重要なのは、バグを再現するための正確な手順を記述することです。

再現プロジェクトは、バグを引き起こす特定の環境を共有するのに適しています。再現プロジェクトは、支援したい人々を助ける最良の方法です。

再現プロジェクトの作成手順#

  • 新しい Git リポジトリを作成します。
  • リポジトリディレクトリで tuist init を使用してプロジェクトを初期化します。
  • 確認したエラーを再現するために必要なコードを追加します。
  • コードを公開し(GitHub アカウントが適しています)、問題を作成する際にそのリンクを貼ります。

再現プロジェクトの利点#

  • 影響範囲の縮小: エラー以外を取り除くことで、バグを探す手間が省けます。
  • 機密コードの公開不要: メインサイトを公開できない場合があります(さまざまな理由により)。その一部を再現テストケースとして再作成することで、機密コードを公開せずに問題を公に示せます。
  • バグの証明: バグはマシンの設定の組み合わせによって発生することがあります。再現テストケースにより、貢献者がビルドを取得して各自のマシンでテストできるため、問題の原因を特定し絞り込むのに役立ちます。
  • バグ修正の支援: 他の人が問題を再現できれば、修正できる可能性が高まります。バグを再現できなければ、修正はほぼ不可能です。