11

GitHubリポジトリからすべてのブランチを構築するTeamCity7.1インストールがあります。

GitHubには、チェックイン時にビルドをトリガーするためのTeamCityへの通知フックがあります。また、TeamCityが120秒ごとにGitHubをポーリングして、変更を確認します（変更がチェックインされたときにサーバーがオフラインだった場合）。

私たちの通常の開発は、一般的なパターンに従います。

  1. マスターからブランチを作成します
  2. 機能が終了するまで、そのブランチにコミットします
  3. 終了したら、マスターからプルして変更をマージし、リモートにプッシュします
  4. GitHubプルリクエストを送信して、管理者がマスターにマージできるようにします

しかし、すべてが順調に機能しています（正しい構成設定を取得するために多くの検索を行った後）...

上記のプロセスはTeamCityでいくつかのビルドをトリガーしますが、それらがすべて必要かどうかを知りたいです。通常、最終的には次のようになります。

  • / refs /heads/ブランチ名のビルド
  • / refs /pull/番号/headのビルド
  • / refs / pull / number /mergeのビルド

当然、最初のビルドは特定のブランチでの最後のチェックインであり、2番目のビルドはプルリクエストですが、3番目のビルドは何のためのものですか？

4

3 に答える 3

13

3番目のビルドは実際に最も価値があります—プルリクエストの自動マージ（githubのボタンを押したときに発生するマージ）の結果です。

于 2012-11-20T11:44:31.267 に答える
3

ビルドは冗長に見えます。gitで機能ブランチのTeamCityビルドを整理するためのより節約的な方法は次のとおりです。

  1. refs/heads/masterブランチの継続的インテグレーションを整理します。ここでは、120秒のポーリングが非常に合理的です。
  2. refs/heads/feature-nameすべてのブランチのナイトリービルドを整理します。私の経験では、120秒のポーリングを必要とする機能ブランチはごくわずかです。

TeamCity 7.1には、機能ブランチを自動トリガーするための非常に優れた機能があるため、ステップ（2）は、のようなブランチマスクを使用して数回クリックするだけでセットアップできますrefs/heads/feature-*。

プルリクエストはマスタービルドでカバーされるため、プルリクエストをビルドしても意味がありません。

于 2012-09-28T08:56:24.407 に答える
0

誰かがまだTeamCityを使用している場合に備えて、回答を更新しました

2018年以降、ネイティブのプルリクエストビルド機能があります。これは、ビルドと対応するPRの間に双方向リンクを作成し、VCSブランチ仕様に追加する必要がないため、ブランチトリガーとフィルターを使用するよりも優れたソリューションrefs/pull/...です。

それでも、使用を主張する場合：GHリポジトリで「線形履歴が必要」（= PRからのリベースとスカッシュのマージのみを許可）機能が有効になっている場合、pull/*/mergeこれにより不要なビルドが作成されることに注意してください。このような場合のPRは、とにかくベースブランチと最新の状態になったらマージしました。

于 2020-11-11T07:54:56.887 に答える