12

TeamCityとGitHubEnterpriseを使用しています。gitでオープンソース風のワークフローを使用しmainlineます。各コンポーネントにリポジトリがあり、人々が変更を加えたい場合は、

  • mainline自分のアカウントにフォークします（したがって、多くのフォークがある可能性があります）
  • フォークにブランチを作成します
  • 変更を実装する
  • mainline/masterその間に発生した変更について最新情報を入手してください
  • fork/feature-branch->のプルリクエストを送信しますmainline/master

このワークフローには非常に満足しています。これは、メインラインが変更を確認する前に、コードレビューを強制します（少なくとも手動の手順で、実際にコードを読み取ってテストを実行する必要があります）。これは歴史的に問題でした。作成者がプルリクエストを見ている人である場合は、GHステータスAPI（ブログ投稿、API doc ）を使用して、マージボタンを緑色以外に切り替えたいと思いますが、それは後で行います。

TeamCity 7.1は、メインラインリポジトリを監視し、変更が確認されたときにビルドするように設定されています。ただし、現在の設定方法では、CIはへの変更を確認した場合にのみビルドされmainline/masterます。

同じワークフローを使用できるようにTeamCityでVCSルートをどのように構成する必要がありますが、CIはメインラインリポジトリのフォークのブランチに基づいてビルドをトリガーしますか？ できれば、すべてのフォークを個別に登録する必要はありませんか？

TeamCity 7.1の機能ブランチのドキュメント（ブログ投稿、リリースノート、ドキュメント）を読みましたが、everyone-commitsではなく任意の数のフォークのモデルに適用する方法がわかりません- to-mainline-in-feature-branchs。

4

2 に答える 2

6

teamcity によるプルリクエストを監視できます: http://blog.jetbrains.com/teamcity/2013/02/automatically-building-pull-requests-from-github-with-teamcity/

于 2014-03-06T10:58:49.480 に答える
4

私の知る限り、TeamCityは自動化された方法でgithubフォークを「探し出す」ことはありません。

これを解決するには、各開発者のフォークされたリポジトリとメインラインリポジトリのvcsルートを作成します。次に、それらの各ルートをビルドにアタッチします。 ドキュメント。

残念ながら、これは手動のプロセスです。開発者ごと、コンポーネントリポジトリごとに1回。これを本当に自動化したい場合は、GithubフックとTeamCityRESTApiを介したvcsルートの追加の組み合わせを検討します。

于 2012-12-02T17:05:06.280 に答える