失敗したテストをどこにプッシュするか？
GitHubリポジトリのブランチ設定を変更したので、[次の]ブランチには、プルリクエストを通じてCIビルドを渡す必要があります。
テストの失敗について、多くのチームメンバーと話し合いました。
状況に応じて...
リポジトリには[master]ブランチがあり、リリースがある場合にのみPRされるため、[master]にはコードas ofが最後のリリースを含みます。メジャー、マイナー、ホットフィックス、ベータ、アルファ/プレリリースビルド。
[next]ブランチは「デフォルト」のブランチであり、ここでintendは「リリース可能な」コードを保持します。技術的には、そのブランチはいつでも[マスター]にPRしてリリースできます。
個々のフォークには独自の開発ブランチがあり、[次へ]への貢献者PRがあります。
重要でないPRをレビューするときは、コントリビューターのdevブランチを「レビュー」ブランチにマージします。問題を迅速に修正できる場合は、変更と新しい（場合によっては失敗する）テスト、およびPRをコミット/プッシュします。コントリビューターのdevブランチに戻ります。彼らが私の変更をマージし、新しい失敗したテストに合格し、次にプッシュすると、PRが同期し、次にPRを[次へ]にマージします。
しかし、この質問はpassingテストについてではなく、-failingテストについてです。
不合格のテストは、修正する必要があることを文書化します。
既知のバグにはテストが書かれているはずなので、何が機能していないかを知ることができます。
技術的にはGitHub issuesリスト（ bug および/または criticallabelsでフィルタリング）もそれを行います。バグを文書化するためにalso失敗したテストをたくさん用意することは良い習慣ですか？
[次へ]でビルドに失敗すると、リリースの準備ができていないことになります...しかし、「リリースの準備ができている」とは、子供を作る準備ができているように見えます-あなたは決してかなりこの準備が整い、そしてsomething、somewhere（変数の重要度が高い）は、必然的にリリースで失敗します。
したがって、合格したテストを[次へ]にプッシュするだけです。失敗したテストをどこにプッシュするのですか？つまり、PR /レビュープロセスの範囲外ですか？
たとえば、ユーザーが問題リストで新しいバグを報告し、そのために失敗したテストスイートを作成したい-何をどこで実行する必要があるかを指定して、新しい貢献者が簡単に見つけられるようにするそして最終的には修正をPRします。
これらの失敗したテストをどこにプッシュすればよいですか？または、失敗したテストをどこかにプッシュするのは良い考えですか？
この状況で私がやろうとしていることは、失敗したテストを「無視」としてマークすることです。そうすれば、テストを維持できるため、将来修正する必要があることを理解できますが、ビルドが壊れてしまうことはありません。 。
問題を修正するために、各テストに問題トラッカーリファレンスのタグも付けると、物事を簡単に結び付けることができます。
完全な開示：私はディスカッションの参加者の1人です。
リポジトリのマスターブランチは、マスターブランチではありません。マスターへのマージは「実際の目的」を提供せず、そのブランチはブランチが行うべきことを実行していません（つまりmove） =）。
あなたはこのブランチを最新リリースへのタグとして悪用しています。
ブランチを使用する代わりに、タグを使用します。リリースしたいときは、トピックブランチと同じように、「リリースブランチ」で必要な手順を実行します。次に、それを[next]にマージして、タグを付けます。
[次の]果たす役割は、マスターブランチの役割です。そこにはリリース対応コードのみが入ります。それ以外は[開発]ブランチになります。開発ブランチには安定化予定の作業が含まれています。つまり、[マスター]を削除し、すでに行った方法で[次へ]転用し、「安定性が低い」作業のために別のブランチを作成します。
失敗するテストが必要であるというルールよりも例外であるため、未解決のバグを思い出させるため、必要に応じて不安定なブランチを作成して破棄することはそれほど問題になりません