0

チェーン化されたビルド構成がいくつかあります。

A
B
C D E

各ビルドには、チェーン内の以前の構成に対するスナップショットの依存関係があります。つまり、ビルドBはAに依存し、ビルドC、D、およびEはBに依存します。

各構成には、チェーン内の前のビルドが正常に完了したときに設定されるトリガーがあります。この設定の問題は、リモート変更をテストするためにパーソナルビルドを実行する場合です。リモート変更がAに対してキューに追加された時点でBが実行されている場合、パーソナルビルドは最初にA(パーソナルビルド)を実行し、C、D、およびEがキューを追加します。これが問題になる理由は、C、D、およびEが、ステップAおよびBでデプロイされたコードに対して実行されるテストであるためです。これは、テストが実行される前に、個人的な変更を加えてコードが効果的に再デプロイされることを意味します。

この問題を解決するための2つの受け入れ可能な方法があります

  1. Aをパーソナルビルドとして実行した後、Aを再キューイングして、C、D、およびEの前にこれらの変更なしで実行します。
  2. Aをパーソナルビルドとして実行した後、テストをすべてのコミットに対して実行することは必須ではないため、ビルドキューからC、D、およびEを削除します。

これらのオプションのいずれかを実装する方法がわかりません。スナップショットの依存関係は現在「適切なビルドがある場合は新しいビルドを実行しない」に設定されていますが、これを変更すると、チェーン全体を再度実行せずに失敗したテストを再実行することはできません。

これはTeamCityを構成するための不適切な方法ですか?もしそうなら、ビルドチェーンを構造化するためのより良い方法は何でしょうか?

4

1 に答える 1

0

私はこの質問で受け入れられた答えを実装することによって問題を解決しました:

TeamCityでビルドチェーンが中断されるのを防ぐことは可能ですか?

このソリューションは、上記のオプション1を実装しました。現在デプロイされている値を含むテキストファイルを利用することで、依存関係が古くなった場合に、HTTPを介してビルドをキャンセル/再トリガーできます。

于 2013-02-11T15:02:04.343 に答える