Git
TeamCity は、Git をすぐにサポートします。Azure DevOps Services を使用した Git ソース管理がサポートされています ( 以下の認証に関する注意事項を参照)。
このページには、VCS ルート設定の Git 固有のフィールドの説明が含まれています。
一般的な VCS ルートプロパティについては、このセクションを参照してください。
注意事項 :
リモート実行とテスト済みのコミットは IntelliJ IDEA プラグインでサポートされています。Visual Studio アドインでは、ブランチリモート実行トリガを使用します。
プロジェクト履歴全体が最初のチェックアウト中にダウンロードされるため、プロジェクト履歴のサイズによっては、Git の最初のチェックアウトにかなりの時間（場合によっては数時間）かかる場合があります。
サーバーでの VCS 関連の操作用のネイティブ Git
TeamCity は、サーバーでの VCS 関連の操作にネイティブ Git を使用できるようになりました。ネイティブ Git を使用すると、以前に使用されていた JGit 実装と比較して、サーバーでの変更操作のチェックのパフォーマンスが向上します。また、大規模な Git リポジトリに関連する多くの問題も修正されています。
TeamCity の現在のネイティブ Git 実装の既知の問題を参照してください。
一般設定
URL を取得 — リモート Git リポジトリからデータを取得するために使用されるリポジトリの URL。サポートされているフォーマットの詳細については、サポートされている Git プロトコルセクションを参照してください。
個々のエージェントのフェッチ URL をオーバーライドして、元の VCS ホスティングではなく、より近いプロキシを使用できるようにすることができます。これを行うには、必要なエージェントの conf/buildAgent.properties ファイルを開き、次のようにリダイレクトルールを追加します:
teamcity.git.fetchUrlMapping.<name> = <source URL> => <target URL>例:teamcity.git.fetchUrlMapping.firstrule = https://example.com/org/test.git => http://proxy.com/test.git部分的なアドレスとアスタリスク (
*) ワイルドカードを使用して、パターンに一致するすべてのフェッチ URL のプロキシを設定できます。例: 次のルールにより、エージェントは元のhttps://example.com/org/test/test.gitの代わりにhttp://proxy.com/test/test.gitURL を使用できます。teamcity.git.fetchUrlMapping.secondrule = https://example.com/org/* => http://proxy.com/フェッチ URL とともに、VCS ルートにはリポジトリへのアクセスに必要な認証設定も保存されることに注意してください。そのため、フェッチ URL の置き換えは、匿名または秘密鍵認証モードを使用する VCS ルートに対してのみ有効です。他のモードでは、エージェントがリポジトリにアクセスできることが保証されません (たとえば、ソース VCS 用に発行されたリフレッシュ可能なトークンは、プロキシホスティングでは受け入れられません)。
プッシュ URL — VCS ラベリングビルド機能によって作成されたアノテーション付きタグをリモートリポジトリにプッシュするために使用されるターゲットリモート Git リポジトリの URL。空白の場合は、フェッチ URL が使用されます。
デフォルトブランチ - デフォルトはブランチです。ここではパラメーター参照がサポートされています。デフォルト値は
refs/heads/masterです。ブランチ仕様 — 機能ブランチのサポートに必要なブランチ名のパターンをリストします。デフォルトのブランチに加えて、一致したブランチの変更も監視されます。構文はチェックアウトルール
+|-:branch_nameに似ています。ここで、branch_nameは VCS に固有です。つまり、Git のrefs/heads/です (オプションの*プレースホルダーを使用)。ブランチとしてタグを使用 — ブランチとして git タグを監視 / チェックアウトできるようにし、ブランチ仕様をブランチと同様にタグ名と一致させます (たとえば、
+|-:refs/tags/<tag_name>)。デフォルトでは、タグは無視されます。ユーザー名スタイル — TeamCity が VCS 変更のユーザー名を報告する方法を定義します。ユーザー名のスタイルを変更すると、新しく収集された変更にのみ影響します。古い変更は、変更を収集した時点でアクティブだったスタイルで引き続き保存されます。
サブモジュール — サブモジュールリポジトリをチェックアウトするかどうかを指定します。複数レベルのサブモジュールを設定する場合は、「チェックアウト」(リポジトリツリー全体を再帰的に取得) モードと「非再帰チェックアウト」(メインリポジトリによって直接参照されるサブモジュールのみを取得) モードを選択できます。下のダイアグラムでは、サブモジュール A と B は両方のモードで使用できますが、サブモジュール C と D には再帰的な「チェックアウト」モードが必要です。
Main_Repo | |_________ Tier 1 Submodule A | | | |_________ Tier 2 Submodule C | |_________ Tier 1 Submodule B | |_________ Tier 2 Submodule Dサブモジュールリポジトリは、認証を必要としないか、同じプロトコルを使用して、VCS ルートで設定されているのと同じ認証を受け入れる必要があります。それ以外の場合は、LFS とサブモジュールのサポートセクションに従って、これらのリポジトリにアクセスするための追加の資格情報を設定する必要があります。
タグ / マージのユーザー名 — ラベル付けに使用されるカスタムユーザー名。
ブランチマッチングルール
ブランチがパターンのない行に一致すると、その行が使用されます。
ブランチが複数の行とパターンを一致させる場合は、最も一致する行が使用されます。
一致する行が複数ある場合は、以下の行が優先されます。
ワイルドカードで一致するものはすべて、TeamCity インターフェースにブランチ名として表示されます。例:+:refs/heads/*はrefs/heads/feature1ブランチと一致しますが、TeamCity インターフェースでは、ブランチ名としてfeature1のみが表示されます。
ブランチの短縮名は次のように決定されます。行に括弧が含まれていない場合は、最初のパターン一致文字から最後のパターン一致文字までのパターンまたは行の一部がない場合は、行全体が使用されます。
行に括弧が含まれている場合は、括弧内の行の一部が使用されます。ここでブランチが指定されていて、あなたのビルド設定が VCS トリガーを持っていて、何らかのブランチに変更が見つかった場合、TeamCity はこのブランチでビルドをトリガーします。
サポートされている Git プロトコル
Git リポジトリの URL では、以下のプロトコルがサポートされています。
SSH（例:
ssh://git.somwhere.org/repos/test.git、ssh://git@git.somwhereElse.org/repos/test.git、SCP ライクな構文）:git@git.somwhere.org:repos/test.git)Git (たとえば、
git://git.kernel.org/pub/scm/git/git.git)HTTP (たとえば、
http://git.somewhere.org/projects/test.git)file (たとえば、
file://c:/projects/myproject/.gitまたは\\servername\projects\myproject\.git)
認証設定
匿名 - 匿名の読み取りアクセスでリポジトリを複製するには、このオプションを選択します。
パスワード / 個人アクセストークン — 有効なユーザー名 (クローン URL にユーザー名がない場合、このフィールドで指定されたユーザー名が URL のユーザー名を上書きします) と、リポジトリのクローン作成に使用するパスワードを指定します。
エージェント側のチェックアウトの場合、エージェントに Git 1.7.3\+ クライアントの場合のみがインストールされていればサポートされます。TW-18711(英語) を参照してください。
Team Foundation Server 2013 からホストされる Git の場合は、ここで NTLM 資格情報を指定します。GitHub、Azure DevOps Services、GitLab、JetBrains Space、および Bitbucket での認証には、パスワードの代わりに個人アクセストークンを使用できます。Azure DevOps に接続するときは、TeamCity からアクセスするリポジトリで、コードアクセススコープをバージョン管理設定のコード（読み取り）/ コード（読み取りと書き込み）に設定することを忘れないでください。
既存の Bitbucket クラウド、Bitbucket サーバー、GitLab または Azure DevOps Services 接続を使用して VCS ルートを作成する場合、TeamCity はパスワードの代わりにリフレッシュ可能なトークンを使用します。
リフレッシュ可能なトークン — GitHub、GitHub App、Bitbucket サーバー、Bitbucket Cloud、Azure DevOps、GitLab、JetBrains Space からデータを取得する VCS ルートが TeamCity 接続を使用して設定されている場合、リフレッシュ可能なトークンはデフォルトで有効になります。
リフレッシュ可能なアクセストークンは、既存の OAuth 接続を介して必要な VCS プロバイダーから TeamCity によって取得される短命のトークンです (VCS ホスティング側のユーザーが手動で発行する静的 PAT トークンとは対照的です)。リフレッシュ可能なトークンの生成と使用の詳細については、次の記事を参照してください: リフレッシュ可能なアクセストークンの管理。
クローン (フェッチ) URL にユーザー名がない場合、ユーザー名を指定できます。ここで指定したユーザー名は、URL のユーザー名よりも優先されます。
秘密鍵 — SSH プロトコルにのみ有効です。秘密鍵は OpenSSH フォーマットに存在する必要があります。
秘密鍵リストからオプションの 1 つを選択し、有効なユーザー名を指定します (クローン URL にユーザー名がない場合、ここで指定したユーザー名が URL のユーザー名よりも優先されます)。
利用可能な秘密鍵オプション:アップロードされたキー — プロジェクトにアップロードされたキーを利用するには、このオプションを選択します。
デフォルトの秘密鍵 — このオプションを選択すると、一般的な ssh ツールで使用されるデフォルトの場所にあるファイルシステムで使用可能なキーが使用されます。ファイルが存在する場合は
<USER_HOME>/.ssh/configで指定されたマッピング、または秘密鍵ファイル<USER_HOME>/.ssh/id_rsa(ファイルはサーバー上に存在する必要があり、またエージェント側のチェックアウトが使用されている場合はエージェントで)。カスタム秘密鍵 — サポートされているサーバー側チェックアウトのみ。秘密鍵パスフィールドに、サーバーマシン上の秘密鍵ファイルへの絶対パスを入力します。キーが暗号化されている場合は、対応するフィールドにパスフレーズを指定します。
GitHub に接続するために利用可能なすべてのオプションについては、コメント(英語)を参照してください。
Azure DevOps サービスへの認証
Azure DevOps Services で Git ソース管理を使用する場合は、Azure DevOps OAuth 接続と Azure DevOps PAT 接続の両方を使用できます。
サーバー設定
これらは、サーバー側チェックアウトの場合に使用される設定です。
オプション | 説明 |
|---|---|
改行コードを CRLF に変換 | すべてのテキストファイルの行末を CRLF に変換します（リポジトリ設定で |
エージェント設定
これらはエージェント側チェックアウトの場合に使用される設定です。
エージェント側のチェックアウトでは SSH のサポートが制限されていることに注意してください。サポートされている認証方法は、「デフォルトの秘密鍵」と「アップロードされた秘密鍵」のみです。
エージェント側のチェックアウトを使用する場合は、エージェントに Git 1.6.4+ をインストールする必要があります。
オプション | 説明 |
|---|---|
Git へのパス | エージェントで使用する Git 実行可能ファイルへのパスを指定します。 |
チェックアウトポリシー | この設定は、TeamCity がビルドエージェントへのチェックアウトを実行する方法を定義します。
|
クリーンポリシー / クリーンファイルポリシー | エージェントで ビルド構成が複数の VCS ルートに依存している場合は、VCS チェックアウトルールを使用して、これらのルートごとに個別のエージェントチェックアウトディレクトリを構成することをお勧めします。このように、 |
エージェントで Git 実行可能ファイル
TeamCity では、エージェント側のチェックアウトを使用するために、エージェント上に Git コマンドラインクライアントバージョン 1.6.4\+ が必要です。
推奨される方法は、git クライアントが TeamCity エージェントの PATH で使用可能であることを確認し、VCS ルートの「git へのパス」設定を空白のままにしておくことです。
一部のマシンに git コマンドラインしかない場合は、VCS ルートの「git へのパス」設定を %env.TEAMCITY_GIT_PATH% 値に設定します。
Git をエージェントの PATH に追加する代わりに、TEAMCITY_GIT_PATH 環境変数（またはエージェントの buildAgent.properties ファイルの env.TEAMCITY_GIT_PATH プロパティ）を git 実行可能ファイルへのフルパスに設定できます。
TEAMCITY_GIT_PATH が定義されていない場合、Git エージェントプラグインはエージェントの起動時にインストールされている git を検出しようとします。最初に次の場所から git を実行しようとします。
Windows の場合 — 次の場所で
git.exeを実行しようとします。C:\Program Files\Git\binC:\Program Files (x86)\Git\binC:\cygwin\bin
* nix の場合 — 次の場所で
gitを実行しようとします。/usr/local/bin/usr/bin/opt/local/bin/opt/bin
これらの場所のいずれにも Git が見つからない場合は、PATH 環境変数を介してアクセス可能な git を実行しようとします。
互換性のある git (1.6.4\+) が見つかった場合は、TEAMCITY_GIT_PATH 環境変数で報告されます。この変数は、VCS ルート設定の git へのパスフィールドで使用できます。その結果、このような VCS ルートを含む構成は、エージェントプロパティで Git が検出されたか指定されたエージェントでのみ実行されます。
LFS とサブモジュールのサポート
共通情報
サブモジュールと LFS は、ソースコードが Git ベースのバージョン管理システムに保存されている多くの複雑なソフトウェア製品の不可欠な部分です。
サブモジュール(英語)を使用すると、Git リポジトリを他の Git リポジトリのサブディレクトリとして保持できます。例: 組織内の別のチームによって開発されたマイクロサービスや、コードが依存するサードパーティのオープンソースプロジェクトを含めたい場合があります。その結果、コミットを別々に保ちながら、リポジトリを親プロジェクトに複製できます。
大容量ファイルストレージ (LFS)(英語) を使用すると、かさばるファイル (メディアファイル、データベースなど) を外部ストレージに移動し、これらのファイルをポインターに置き換えることで、リポジトリのサイズを大幅に削減できます。
シナリオと実装メカニズムは異なりますが、どちらのコンセプトも、外部ソース (リモート LFS サーバーまたは VCS 内の別のリポジトリでホストされているファイル) から重要なプロジェクトコンポーネントを組み込むことを提案しています。つまり、TeamCity プロジェクトは、ソースファイルをチェックアウトするためにさまざまなリソースに対して認証する必要があります。
追加の資格
リポジトリが同じ VCS でホストされているサブモジュールをインポートし、これらのインポートされたリポジトリに VCS ルートの設定に保存されている同じ資格情報を使用してアクセスできる場合は、追加の変更を行う必要はありません。TeamCity は、単一の資格情報セットを使用して、必要なすべてのソースファイルをチェックアウトします。
それ以外の場合、TeamCity が外部 LFS サーバーまたは必要なサブモジュールをホストする別の VCS にアクセスする必要がある場合は、プロジェクトに 3 つの構成パラメーターを追加する必要があります。
<別名> は、
teamcity.git.https.credentials...プロパティを 3 つのセットにグループ化するカスタム文字列で、必要なプロパティを識別するために使用されます。例: GitHub リポジトリがソナタイプネクサス (英語) LFS から大きなファイルをインポートし、Azure DevOps から追加のサブモジュールをインポートする必要がある場合、6 つのプロパティが必要になります。そのうち 3 つにはnexusエイリアスを持たせることができ、残りにはazureエイリアスを持たせることができます。TeamCity が Azure サブモジュールリポジトリにアクセスする必要がある場合、URL が...azure.urlプロパティに格納されていることを認識し、同じエイリアス (...azure.usernameおよび...azure.password) を持つ一致するプロパティを探します。URL は、サブモジュールリポジトリの HTTP(S) フェッチ URL または LFS ストレージへの HTTP(S) リンクです。例:
https://github.com/username/submodule-repo-name.gitまたはhttps://mynexus.com/repository/repo-name/info/lfsSSH プロトコルは現在サポートされていません。ユーザー名とパスワードは、対応するサービスの資格情報を格納します。通常のリポジトリへのアクセスに通常適用されるすべての制限とガイドラインは、LFS/ サブモジュールのチェックアウトにも適用されることに注意してください。例:
...passwordプロパティは、通常のアカウントパスワードの代わりにアクセストークンを格納する必要があります。後者のオプションは、Git ホスティングの大半で継続的に廃止されているためです。...usernameプロパティは、アクセストークンと組み合わせて使用できる値も格納する必要があります (たとえば、GitHub および GitLab の通常のアカウント名、または Bitbucket Cloud の "x-token-auth")。次も参照してください。
制限事項とヒント
追加の資格情報を保存する構成プロパティは、ビルド構成ではなく、TeamCity プロジェクトに対して構成する必要があります。
セキュリティ上の理由から、すべての
...passwordパラメーターをパスワード型に切り替えます。これにより、トークンとパスワードが TeamCity UI、ビルドログ、Kotlin DSL および REST API ペイロードから非表示になります。さらに、潜在的な攻撃者がこのパラメーターに独自の URL を書き込んで認証トークンを盗むのを防ぐために、teamcity.git.https.credentials.<ALIAS>.urlパラメーターの読み取り専用設定を有効にすることをお勧めします。
以前のバージョンには脆弱性の悪用(英語)が含まれているため(英語)、Git LFS バージョン 2.12.1 以降を使用することをお勧めします。
TeamCity は、エージェント側のチェックアウトに対してのみ Git LFS をサポートします。
追加の VCS 認証情報は、LFS オブジェクトが別のストレージに保存されている場合にのみ必要です。この場合、TeamCity VCS ルートでは HTTP 認証が必要であり、SSH はサポートされていません。この制限は、LFS オブジェクトが Git ホスティングに保存されている場合には適用されません。
エージェント側のチェックアウトルールの制限事項
Git プラグインは、 git sparse-checkout (英語) を使用してエージェント上の Git ファイルをチェックアウトします。プラグインは、Git でサポートされる VCS チェックアウトルールのセットを制限する単純なファイルマッピング操作のみを実行できます。
次のルールがサポートされています。
ルールはファイルを再マップしてはならないことに注意してください。つまり、次のルールはサポートされていません : +:dirA/dirA1 => dirA/dirA2
1 つのルートに複数のチェックアウトルールを指定する場合は、それらのチェックアウトディレクトリ (ルールの右側の部分) に共通の親ディレクトリ ([prefix/]) があることを確認してください。エージェント側のチェックアウトではルール +:dirA => [prefix/]dirA のみがサポートされており、[prefix/] はすべてのルールで同じである必要があります。
例:
次のルールはサポートされていないことに注意してください: +:dirA=>[prefix/]dirA/postfix チェックアウトディレクトリパスに [/postfix] を追加し、構成の VCS チェックアウトモードが「エージェント上のファイルを常にチェックアウトする」に設定されている場合、新しいビルドを開始できません。
関連ページ：
VCS ルートの設定
VCS ルートは、TeamCity ←→ VCS リポジトリ通信の基礎です。この不可欠な要素は、リポジトリのチェックアウト、コードソースのタグ付け、ビルドステータスの VCS への返信など、さまざまな操作を実行するために必要な VCS プロバイダーへの接続を定義します。VCS ルートには次の情報が保存されます。TeamCity がリモートファイルをプルおよびプッシュするために使用する URL を取得してプッシュします。ブランチ情報: TeamCity が追跡する必要があるリポジトリブランチのリスト...
VCS チェックアウトモード
ビルド構成のバージョン管理設定ページでは、プロジェクトのソースコードを VCS から取得する方法を構成できます。VCS ルートを接続してチェックアウトオプションを構成できます。VCS チェックアウトモードは、プロジェクトソースがエージェントに到達する方法に影響する設定です。このモードは、ソースのチェックアウトのみに影響します。現在のリビジョンおよび変更データの取得ロジックは TeamCity サーバーによって実行されるため、TeamCity サーバーはどのモードでも VCS サーバーにアクセスする...
VCS ラベリング
TeamCity は、バージョン管理システムで特定のビルドのソースに（自動または手動で）ラベルを付ける（タグを付ける）ことができます。適用されたラベルとその適用ステータスのリストは、ビルド結果の変更タブに表示されます。自動 VCS ラベル付け：TeamCity を設定して、ビルドのステータスに応じてビルドのソースに自動的にラベルを付けることができます。ラベル付けは標準の通知イベントではありません。ビルドが終了した後にバックグラウンドで実行され、ビルドステータスには影響しません。ただし、現在のビ...
機能ブランチを使用した作業
分散バージョン管理システム (DVCS) の機能ブランチを使用すると、メインの開発とは独立して機能に取り組み、機能のすべての変更をブランチにコミットし、機能が完了したら変更をメインのブランチにマージできます。このアプローチは、ソフトウェア開発チームに多くの利点をもたらしますが、専用のサポートがない継続的インテグレーションサーバーでは、ビルド構成の重複が頻繁に発生したり、可視性が低下したり、最終的にはプロセスに対する制御が失われるなど、多くの問題も発生します。機能ブランチの TeamCity サポ...
カスタムパラメーターの作成と設定
このトピックでは、カスタム TeamCity パラメーターを作成し、その外観と動作を構成する方法について説明します。名前の制限：構成パラメーターの名前には、文字のみが含まれ、ASCII 文字で始まる必要があります。新しいパラメーターを作成する方法：TeamCity UI 内プロジェクトまたは構成設定に移動し、パラメータータブに切り替えます。パラメーターの優先順位と継承ルールについては、この記事を参照してください: パラメーター値。入力パラメータータブに切り替えます。出力パラメーターはビルドチェ...
接続を構成
TeamCity 接続は、外部サービスへのアクセスに必要な資格情報を保存します。このサードパーティサービスの種類に基づいて、2 つの主要な接続カテゴリがあります。VCS 接続これらの接続は、GitHub、GitLab、Bitbucket クラウドなどの VCS プロバイダーへのアクセスに必要な情報を保存します。これらの接続は、プロジェクト、ビルド構成、パイプラインを最も速く作成する方法を提供します。認証は自動的に処理されるため、リポジトリを選択するだけでビルドステップの設定を開始できます。接続が...