TeamCity On-Premises 2026.2 Help

Git

TeamCity は Git をすぐに使える状態でサポートしています。 Azure DevOps Services を使用した Git ソース管理がサポートされています (以下の認証に関する注意事項を参照)。

このページでは、VCS ルート設定の Git 固有フィールドについて説明します。
共通の VCS ルートプロパティについては、 このセクションを参照してください。

重要な注記 は:

サーバー上の VCS 関連操作にネイティブ Git を使用する

TeamCity は、サーバー上の Git 操作のデフォルトオプションとしてネイティブ Git を使用できるようになりました。 ネイティブ Git に切り替えると、以前に使用された JGit 実装と比較して、サーバーでの変更操作のチェックのパフォーマンスが向上します。 また、大規模な Git リポジトリに関連する多くの問題も修正されています。

切り替える前に、 ネイティブ Git クライアント(英語)バージョン 2.29 以降がサーバーマシンにインストールされ、その実行可能ファイルへのパスが パス 環境変数に指定されていることを確認してください。 または、 TeamCity.サーバー.Git.実行可能ファイル.パス 内部プロパティを使用して実行可能ファイルへのフルパスを設定することもできます (サーバーの再起動は不要です)。 Windows では、パスに二重の円記号を使用することを忘れないでください。

TeamCity サーバーをネイティブ Git に切り替えるには、 管理 | 診断 に移動し、 Git タブを開きます。 ここでは、サーバー上の任意の VCS ルートでネイティブ Git を介した接続をテストできます。 すべての VCS ルートをテストすることを選択した場合、TeamCity は JGit 経由で正常に接続できるかどうかを確認してから、ネイティブ Git 経由の接続をテストします。 この対策は、ネイティブ Git に切り替えた後にパイプラインが破損しないようにできます。 接続テストが成功した場合は、サーバーでネイティブ Git サポートを有効にできます。

一般設定

  • フェッチ URL — リモート Git リポジトリからデータを取得するために使用されるリポジトリの URL。 サポートされているフォーマットの詳細については、 サポートされている Git プロトコル セクションを参照してください。

    個々のエージェントのフェッチ URL をオーバーライドして、元の VCS ホスティングではなく、より近いプロキシを使用できるようにすることができます。 これを行うには、必要なエージェントの conf/buildAgent.properties ファイルを開き、次のようにリダイレクトルールを追加します： teamcity.git.fetchUrlMapping.<お名前> = <ソース URL> => <ターゲット 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.git URL を使用できます。

    teamcity.git.fetchUrlMapping.secondrule = https://example.com/org/* => http://proxy.com/

    フェッチ URL とともに、VCS ルートにはリポジトリへのアクセスに必要な認証設定も保存されることに注意してください。 そのため、フェッチ URL の置き換えは、 匿名 または 秘密鍵 認証モードを使用する VCS ルートに対してのみ有効です。 他のモードでは、エージェントがリポジトリにアクセスできることが保証されません (たとえば、ソース VCS 用に発行されたリフレッシュ可能なトークンは、プロキシホスティングでは受け入れられません)。

  • プッシュ URL - VCS ラベリングビルド機能で作成されたアノテーション付きタグをリモートリポジトリにプッシュするために使用される、ターゲットリモート Git リポジトリの URL。 空白の場合は、フェッチ URL が使用されます。

  • デフォルトブランチ - デフォルトはブランチです。 ここでパラメーター参照がサポートされています。 デフォルト値は refs/heads/マスター です。

  • ブランチ仕様 — 機能ブランチのサポートに必要な、ブランチ名のパターンを一覧表示します。 一致したブランチは、デフォルトブランチに加えて変更が監視されます。 構文はチェックアウトルールに似ています: +|-:ブランチ名 。ここで ブランチ名 は VCS 固有です。つまり、Git では refs/heads/ です (オプションの * プレースホルダーを使用)。

  • ブランチとしてタグを使用 — ブランチとして git タグを監視 / チェックアウトできるようにし、ブランチ仕様をブランチと同様にタグ名と一致させます (たとえば、 +|-:refs/tags/<タグ名>)。 デフォルトでは、タグは無視されます。

  • ユーザー名のスタイル - 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を参照してください。
    チーム Foundation サーバー 2013 でホストされている Git の場合は、ここで NTLM 資格情報を指定します。

    GitHub、Azure DevOps Services、GitLab、JetBrains Space、および Bitbucket での認証には、パスワードの代わりに個人アクセストークンを使用できます。 Azure DevOps に接続する場合は、TeamCity からアクセスするリポジトリで、 Codeアクセススコープを バージョン管理設定用の Code (read) / Code (read and write)に設定してください。

    既存の Bitbucket Cloud、Bitbucket サーバー、GitLab または Azure DevOps Services 接続を使用して VCS ルートを作成する場合、TeamCity はパスワードの代わりにリフレッシュ可能なトークンを使用します。

  • 更新可能なトークン — GitHub、GitHub アプリ、Bitbucket サーバー、Bitbucket Cloud、Azure DevOps、GitLab、または JetBrains Space からデータを取得する VCS ルートが TeamCity の 接続を使用して設定されている場合、リフレッシュ可能なトークンはデフォルトで有効化されます。

    リフレッシュ可能なアクセストークンは、既存の OAuth 接続を介して必要な VCS プロバイダーから TeamCity が取得する有効期間の短いトークンです (VCS ホスティング側でユーザーが手動で発行する静的 PAT トークンとは異なります)。 リフレッシュ可能なトークンの生成と使用の詳細については、次の記事を参照してください: 更新可能なアクセストークンを管理する。

    クローン (フェッチ) URL にユーザー名がない場合、ユーザー名を指定できます。 ここで指定したユーザー名は、URL のユーザー名よりも優先されます。

  • 秘密鍵 — SSH プロトコルにのみ有効です。 秘密鍵は OpenSSH フォーマット に存在する必要があります。

    秘密鍵 リストからいずれかのオプションを選択し、有効なユーザー名を指定します (クローン URL にユーザー名がない場合、ここで指定したユーザー名が URL のユーザー名をオーバーライドします)。
    利用可能な 秘密鍵 オプション：

    • アップロード済みの鍵 — プロジェクトにアップロードされたキーを利用するには、このオプションを選択します。

    • デフォルトの秘密鍵 — このオプションを選択すると、一般的な ssh ツールで使用されるデフォルトの場所にあるファイルシステム上の鍵を利用できます: ファイルが存在する場合は <ユーザーホーム>/.ssh/config で指定されたマッピング、または秘密鍵ファイル <ユーザーホーム>/.ssh/id_rsa (これらのファイルはサーバー上に存在する必要があります。また、 エージェント側チェックアウト を使用する場合はエージェント上にも存在する必要があります)。

    • カスタム秘密鍵 — サポートされている サーバー側チェックアウトの場合のみ。 秘密鍵のパス フィールドに、サーバーマシン上の秘密鍵ファイルへの絶対パスを入力します。 キーが暗号化されている場合は、対応するフィールドにパスフレーズを指定します。

GitHub に接続するために利用可能なすべてのオプションについては、 コメント(英語)を参照してください。

Azure DevOps Services への認証

Azure DevOps Services で Git ソース管理を使用する場合は、 Azure DevOps OAuth 接続と Azure DevOps PAT 接続の両方を使用できます。

サーバー設定

これらは、サーバー側 チェックアウトの場合に使用される設定です。

オプション

説明

改行コードを CRLF に変換

すべてのテキストファイルの行末を CRLF に変換します（リポジトリ設定で core.autocrlf=true を設定するように機能します）。 選択しない場合、行末変換は実行されません（core.autocrlf=false の設定として機能します）。 サーバー側のチェックアウトにのみ影響します。 このプロパティを変更すると、清潔なチェックアウトが行われます。

エージェント設定

これらは、エージェント側の チェックアウトで使用される設定です。
エージェント側チェックアウトでは SSH のサポートが制限されていることに注意してください。 サポートされている認証メソッドは "デフォルト秘密鍵" と "アップロード済み秘密鍵" のみです。
エージェント側チェックアウトを使用するプランがある場合は、エージェントに Git 1.6.4+ がインストールされている必要があります。

オプション

説明

Git へのパス

エージェントで使用する Git 実行可能ファイルへのパスを指定します。 %env.TEAMCITY_GIT_PATH% に設定すると、自動検出された Git が使用されます。詳細は エージェント上の Git 実行可能ファイルを参照してください。

チェックアウトポリシー

この設定は、TeamCity がビルドエージェントにチェックアウトを実行する方法を定義します。

  • 鏡を使う: 寿命の長いエージェントに推奨されます。 このオプションを選択すると、TeamCity はエージェントマシンの system/caches/git ディレクトリの下にリモートリポジトリキャッシングを作成します。 その後、ビルドチェックアウトディレクトリを更新するときに、 キャッシュが代替(英語)として追加されます。 このリポジトリの次のチェックアウトを高速化するために、エージェントは同じフェッチ URL を持つすべてのビルドでキャッシュを再利用します。 これにより、クリーンチェックアウトが高速化され（ビルド作業ディレクトリのみがクリーンアップされるため）、ディスクスペースが節約されます（ミラーはエージェント上の特定のリポジトリの唯一のクローンであるため）。

  • ミラーを使用しない: ミラーを作成せずに、 ビルドチェックアウトディレクトリに直接チェックアウトすることを選択します。 Less はミラーよりもディスク使用量の点で最適ですが、既存の構成との下位互換性のために保持されています。

  • シャロークローン: 存続期間の短いエージェントに推奨されます。たとえば、各ビルド後に終了される使い捨てのクラウドエージェントに適しています。 必要なリビジョンをひとつだけフェッチして シャロークローンを作成するため、ビルド開始時の時間を節約できます。 ビルドで Git コミット履歴が不要で、クラウドイメージに新しい Git ミラーが含まれていない場合にのみ、このオプションを選択してください。 teamcity.git.shallowClone=true エージェント構成プロパティを指定することで、特定のエージェントに対してこのオプションを強制できます。

  • 自動: TeamCity は、 teamcity.cloud.agent.terminate.after.build エージェント構成プロパティとエージェント上のミラーの有無に応じて、上記のアプローチのいずれかを自動的に適用します。

クリーンポリシー / クリーンファイルポリシー

エージェントで git clean コマンドを実行するとき、およびどのファイルを除去するかをここで指定してください。

ビルド構成が複数の VCS ルートに依存している場合は、 VCS チェックアウトルールを使用して、これらのルートごとに個別のエージェントチェックアウトディレクトリを構成することをお勧めします。 このように、 git clean はクリーニング中にこれらのチェックアウトディレクトリを削除しません。

エージェント上の Git 実行可能ファイル

TeamCity でエージェント側チェックアウトを使用するには、エージェントに Git コマンドラインクライアントバージョン 1.6.4\+ が必要です。

推奨される方法は、TeamCity エージェントの パス で git クライアントが利用できることを確認し、VCS ルートの "git へのパス" 設定を空のままにすることです。
一部のマシンにのみ git コマンドラインがある場合は、VCS ルートの "git へのパス" 設定を %env.TEAMCITY_GIT_PATH% 値に設定します。

Git をエージェントの PATH に追加する代わりに、 TEAMCITY_GIT_PATH 環境変数（またはエージェントの ビルドエージェント.プロパティ ファイルの env.TEAMCITY_GIT_PATH プロパティ）を git 実行可能ファイルへのフルパスに設定できます。

TEAMCITY_GIT_PATH が定義されていない場合、Git エージェントプラグインはエージェントの起動時にインストールされている git を検出しようとします。 最初に次の場所から git を実行しようとします。

  • Windows の場合 — 次の場所で git.exe を実行しようとします。

    • C:\Program Files\Git\bin

    • C:\Program Files (x86)\Git\bin

    • C:\cygwin\bin

  • * nix の場合 — 次の場所で Git を実行しようとします。

    • /usr/local/bin

    • /usr/bin

    • /opt/local/bin

    • /opt/bin

これらの場所のいずれにも Git が見つからない場合、 パス 環境変数からアクセスできる git の実行を試みます。
互換性のある git (1.6.4\+) が見つかった場合、 TEAMCITY_GIT_PATH 環境変数で報告されます。 この変数は、 VCS ルート設定の git へのパス フィールドで使用できます。 その結果、このような VCS ルートを持つ構成は、Git が検出されたかエージェントプロパティで指定されたエージェントでのみ実行されます。

クラウドエージェント上の Git ミラー

デフォルトでは、TeamCity は ミラー 、つまり Git リポジトリのコピーを、エージェントの system/git ディレクトリの下に作成します。 ソースファイルのフェッチにかかる時間とディスク容量を節約するため、TeamCity はビルドのチェックアウトディレクトリを更新するときに Git alternate メカニズムを介してこのミラーを参照します。

セルフホストの TeamCity エージェントと比較すると、クラウドエージェントでは Git ミラーを追加するために追加のステップが必要です：

  1. クラウドイメージを準備する場合は、エージェントイメージの system/git ディレクトリ下のリポジトリをクローンします。 必要に応じて、複数の *.git ディレクトリを並べて保存できます。

  2. system/git ディレクトリに マップ ファイルを作成し、元のリポジトリとそのミラー間のマッピングを記述します。 例:

    ssh://git@<host>/<git_folder>.git = <git_folder>.git

ビルドを開始すると、クラウドエージェントは マップ ファイルで指定されたミラーを確認し、必要な origin とそのミラーとの差分をフェッチします。 マップ ファイルの origin URL は、VCS ルートに設定された URL と一致する必要があります。
このようにすると、新しいクラウドエージェントが起動するたびにリモートリポジトリ全体をチェックアウトする必要がなくなり、ビルドが大幅に速く実行されます。

サーバー上の Git ガベージコレクションの構成

TeamCity サーバーは、サーバー上で構成された VCS ルートで使用されるすべての Git リポジトリについてローカルクローンを維持します。 サーバーはこれらのクローンで日に何度もフェッチを実行するため、予測可能なパフォーマンスを維持するには、クローンを定期的に最適化する必要があります。 クローンに対して Git ガベージコレクションが長期間実行されていない場合、変更を収集する処理が遅くなったり、メモリ関連のエラーを報告し始めたりすることがあります。
サーバー上でネイティブ Git クライアントが見つかる場合、TeamCity は git gc を定期的に自動実行できます。 Git GC を実行できない場合、関連するヘルスレポートが生成されます。

警告を修正する / 自動 git gc 要件を満たすには、次を実行します。

  1. TeamCity サーバーにネイティブ Git クライアントを手動でインストールします。

  2. Git 実行可能ファイルへのパスを指定します。

    • 実行可能ファイルを含むディレクトリを パス 環境変数に追加してサーバーを再起動する、 または

    • サーバーを再起動せずに、 TeamCity.サーバー.Git.実行可能ファイル.パス 内部プロパティで実行可能ファイルへのフルパスを設定します。 Windows では、パスに二重の円記号を使用することを忘れないでください。

TeamCity が Git ガベージコレクションを実行すると、詳細は teamcity-cleanup.log に記録されます。 git ガベージコレクションが失敗した場合、対応する警告が表示されます。

TeamCity は合計時間が 5 時間のクォータを超えない範囲で Git ガベージコレクションを実行します。このクォータは TeamCity.サーバー.Git.GC.クォータ.分 内部プロパティを使用して変更できます。
Git ガベージコレクションは毎晩 2 AM に実行されます。 これは、次のような cron 式を内部プロパティに指定することで変更できます: teamcity.git.cleanupCron=0 0 2 * * ？。 git gc プロセスの動作が遅く、割り当てられた時間内に完了できない場合は、デフォルトの Git 構成ファイルで git-repack 構成を確認してください (たとえば、 git gc のパフォーマンスを向上させるために --window-memory を増やすことができます)。

ローカル Git クローンに何らかの手動メンテナンスが必要な場合は、 <TeamCity データディレクトリ>/system/caches/git ディレクトリにあります。 ディレクトリ内の マップ ファイルには、リポジトリ URL とリポジトリのベアクローンを格納するサブディレクトリ間のマッピングが含まれています。

LFS とサブモジュールのサポート

共通情報

サブモジュールと LFS は、ソースコードが Git ベースのバージョン管理システムに保存されている多くの複雑なソフトウェア製品の不可欠な部分です。

  • サブモジュール(英語)を使用すると、Git リポジトリを他の Git リポジトリのサブディレクトリとして保持できます。 例: 組織内の別のチームによって開発されたマイクロサービスや、コードが依存するサードパーティのオープンソースプロジェクトを含めたい場合があります。 その結果、コミットを別々に保ちながら、リポジトリを親プロジェクトに複製できます。

  • 大容量ファイルストレージ (LFS)(英語) を使用すると、かさばるファイル (メディアファイル、データベースなど) を外部ストレージに移動し、これらのファイルをポインターに置き換えることで、リポジトリのサイズを大幅に削減できます。

シナリオと実装メカニズムは異なりますが、どちらのコンセプトも、外部ソース (リモート LFS サーバーまたは VCS 内の別のリポジトリでホストされているファイル) から重要なプロジェクトコンポーネントを組み込むことを提案しています。 つまり、TeamCity プロジェクトは、ソースファイルをチェックアウトするために別々のリソースに対して認証する必要があります。

追加の資格情報

リポジトリが同じ VCS でホストされているサブモジュールをインポートし、これらのインポートされたリポジトリに VCS ルートの構成 に保存されている同じ資格情報を使用してアクセスできる場合は、追加の変更を行う必要はありません。 TeamCity は、単一の資格情報設定を使用して、必要なすべてのソースファイルをチェックアウトします。

それ以外の場合、TeamCity が外部 LFS サーバーまたは必要なサブモジュールをホストする別の VCS にアクセスする必要がある場合は、三つの 構成パラメーターを プロジェクト に追加する必要があります：

teamcity.git.https.credentials.<ALIAS>.url = https://example.com/... teamcity.git.https.credentials.<ALIAS>.username = johndoe teamcity.git.https.credentials.<ALIAS>.password = 081ef11uh

  • <エイリアス> は、 teamcity.git.https.credentials… プロパティを 3 つのセットにグループ化するカスタム文字列で、必要なプロパティを識別するために使用されます。 例: GitHub リポジトリが ソナタイプネクサス (英語) LFS から大きなファイルをインポートし、 Azure DevOps から追加のサブモジュールをインポートする必要がある場合、6 つのプロパティが必要になります。 そのうち 3 つには Nexus エイリアスを持たせることができ、残りには Azure エイリアスを持たせることができます。 TeamCity が Azure サブモジュールリポジトリにアクセスする必要がある場合、URL が ...azure.url プロパティに格納されていることを認識し、同じエイリアスを持つ一致するプロパティを探します: ...azure.ユーザー名 と ...azure.パスワード。

  • URL は、サブモジュールリポジトリの HTTP(S) フェッチ URL、または LFS ストレージへの HTTP(S) リンクです。 例: https://github.com/username/submodule-repo-name.git または https://mynexus.com/repository/repo-name/info/lfs SSH プロトコルは現在サポートされていません。

  • ユーザー名 と パスワード には、対応するサービスの資格情報が保存されます。 通常のリポジトリにアクセスする場合に通常有効なすべての制限事項とガイドラインは、LFS / サブモジュールのチェックアウトにも適用されることに注意してください。 たとえば、 ...パスワード プロパティには、通常のアカウントパスワードではなくアクセストークンを保存する必要があります。これは、後者のオプションが大多数の Git ホスティングで継続的に廃止されているためです。 ...ユーザー名 プロパティにも、アクセストークンと組み合わせて使用できる値を保存する必要があります (たとえば、GitHub や GitLab の通常のアカウントのお名前、または Bitbucket Cloud の "x-token-auth")。 関連事項:

制限事項とヒント

  • 追加の資格情報を保存する構成プロパティは、ビルド構成ではなく TeamCity プロジェクトに対して構成する必要があります。

  • セキュリティ上の理由から、すべての ...パスワード パラメーターを パスワード型に切り替えます。 これにより、トークンとパスワードが TeamCity UI、ビルドログ、Kotlin DSL、REST API ペイロードから非表示になります。 さらに、潜在的な攻撃者がこのパラメーターに独自の URL を書き込んで認証トークンを盗むのを防ぐために、 teamcity.git.https.credentials.<エイリアス>.url パラメーターの 読み取り専用 設定を有効にすることをお勧めします。

    シークレットタイプと読み取り専用プロパティ

  • 以前のバージョンには 脆弱性の悪用が含まれているため、Git LFS バージョン 2.12.1 以降を使用することをお勧めします。

  • TeamCity は エージェント側チェックアウトでのみ Git LFS をサポートします。

  • 追加の VCS 認証情報は、LFS オブジェクトが別のストレージに保存されている場合にのみ必要です。 この場合、TeamCity VCS ルートには HTTP 認証が必要です。SSH はサポートされていません。 この制限は、LFS オブジェクトが Git ホスティングに保存されている場合には適用されません。

内部プロパティ

Git VCS では、次の 内部プロパティを設定できます。

TeamCity.Git.アイドル.タイムアウト.秒

デフォルト値: 1800

リモートリポジトリと通信するためのアイドルタイムアウト。 このタイムアウトの間にデータが送受信されなかった場合、プラグインはタイムアウトエラーをスローして、プロセスが永久にハングするのを防ぎます。

teamcity.git.フェッチ.タイムアウト

デフォルト値: 1800

このプロパティは非推奨です。 git fetch 操作のための TeamCity.Git.アイドル.タイムアウト.秒 のオーバーライド

teamcity.git.フェッチ.別プロセス

デフォルト値: 真

TeamCity が git fetch を別のプロセスで実行するかどうかを指定します

TeamCity.Git.フェッチ.プロセス.最大.メモリ

デフォルト値: なし

このプロパティは明示的な -Xmx を提供し、自動 -Xmx セットアップを無効にします。

構成されたメモリはメインサーバープロセスに加えて使用され、 git fetch と git patch を実行する子プロセスが複数存在し、それぞれが構成された量のメモリを使用する可能性があるため、サーバーマシンに十分なメモリがあることを確認してください。 Git フェッチに -Xmx1024m を超えるヒープメモリを必要とする大規模リポジトリでは、 64 ビット Java への切り替えが必要になる場合があります。

teamcity.git.fetch.process.max.memory.limit

デフォルト値: なし

デフォルトでは、TeamCity は git fetch と git patch 用にネストされた Java プロセスを開始し、これらのプロセスに対して -Xmx を自動的に選択します。

このプロパティは、TeamCity が自動的に設定できる git fetch または git patch の最大可能な -Xmx 値を指定します。

teamcity.git.監視.有効期限.タイムアウト.時間

デフォルト値: 24

フェッチ が別のプロセスで使用される場合、自身のスレッドダンプを作成し、 TEAMCITY_DATA_DIR/システム/キャッシング/git/<git-XXX>/監視 に保存します（ディレクトリマッピングは TEAMCITY_DATA_DIR/システム/キャッシング/git/マップ で確認できます）。 スレッドダンプは、リモートリポジトリからのクローン作成に関する問題の調査に役立ちます。 このパラメーターは、スレッドダンプを保存する期間（時間単位）を指定します。

teamcity.サーバー.git.gc.有効

デフォルト値: 真

サーバーのクリーンアップ中に TeamCity が git gc を実行するかどうかを指定します (ネイティブ git が使用されます)。

TeamCity.サーバー.Git.実行可能ファイル.パス

デフォルト値: Git

サーバー上のネイティブ git 実行可能ファイルへのパス。

TeamCity.サーバー.Git.GC.クォータ.分

デフォルト値: 60

git gc を実行する最大時間（分単位）。

teamcity.git.クリーンアップ Cron

デフォルト値: 0 0 2 \* \* ？ アスタリスク

git-plugin のクリーンアップ時刻を表す クーロン表現(英語)。 デフォルトの式では、毎日午前 2 時にクリーンアップが開始されます。

TeamCity.Git.ストリーム.ファイル.しきい値.MB

デフォルト値: 128

JGit がストリームを使用してオブジェクトをインフレートするしきい値（メガバイト単位）。 リポジトリに大きなバイナリファイルがあり、 TW-14947(英語) に記載されている症状が見られる場合は、この値を増やしてください。

teamcity.git.別プロセスでパッチをビルド

デフォルト値: 真

Git プラグインは別のプロセスでパッチをビルドします。サーバープロセスでパッチをビルドするには、これを false に設定します。 パッチをビルドするには、git プラグインがリポジトリファイルをメモリに読み込む必要があります。 メモリ不足を避けるため、git プラグインはしきい値より小さいサイズのオブジェクトだけを読み込みます。より大きなオブジェクトにはストリームが使用され、遅くなることがあります (TW-14947)。 別のプロセスでパッチをビルドすると、すべてのオブジェクトがメモリに読み込まれます。 パッチプロセスは、別のフェッチプロセスのメモリ設定を使用します。

teamcity.git.ミラー.有効期限.タイムアウト.日数

デフォルト値: 7

未使用のリポジトリのクローンがサーバーマシンから削除されるまでの日数。 変更の確認や現在のバージョンの取得など、このリポジトリに対する TeamCity 操作がなかった場合、リポジトリは未使用と見なされます。 これらの操作はかなり頻繁に行われるため、7 日間というのはかなり高い値です。

teamcity.git.コミット.デバッグ情報

デフォルト値: 偽

見つかったコミットごとに追加のデバッグ情報を記録するかどうかを指定します。

teamcity.git.再パック.アイドルタイムアウト秒

デフォルト値: 1800

git-repack 操作のアイドルタイムアウトを秒単位で定義します。 大規模なリポジトリでは、オブジェクトの再パックに時間がかかるため、このタイムアウトを増やす必要がある場合があります。

teamcity.git.SSH プロキシタイプ

デフォルト値: なし

SSH プロキシの種類。 サポートされている値: http、 socks4、 socks5 socks4 プロキシはリモートホスト名を解決できないことに注意してください。 socks4 プロキシではリモートホストのお名前を解決できないことに注意してください。そのため、UnknownHostException が発生した場合は、socks5 に切り替えるか、TeamCity サーバーマシンの hosts ファイルに git サーバーのエントリを追加してください。

teamcity.git.SSH プロキシホスト

デフォルト値: なし

SSH プロキシホスト。

teamcity.git.SSH プロキシポート

デフォルト値: なし

SSH プロキシポート

teamcity.git.native.sshProxyCmd

デフォルト値: なし

netcat-openbsd なしで Linux マシン上で実行されている TeamCity サーバーには、このプロパティを指定してください。 この場合、SSH 認証を行う Git VCS ルートで 終了コード: 128 stderr: nc: 無効なオプション -- 'X' エラーが発生する可能性があります。 詳細については、 送信 TeamCity サーバー接続にプロキシを使用するセクションの末尾にある注記を参照してください。

teamcity.git.native.sshProxyCmd=ncat --proxy %host:%port --proxy-type http
teamcity.git.接続再試行回数

デフォルト値: 3

失敗を認める前に、接続をテストし、現在のリポジトリの状態を取得するために、リモートホストへの接続を確立しようとする試行回数。

teamcity.git.接続再試行間隔秒

デフォルト値: 4

連続した接続試行間の遅延 (秒単位)。

Git の ビルドパラメーター:

teamcity.git.ネイティブ SSH を使用

デフォルト値: 偽

TeamCity がネイティブ SSH 実装を使用するかどうかを指定します。 このプロパティは「エージェントによるチェックアウト」モードでのみ有効です。

TeamCity.Git.アイドル.タイムアウト.秒

デフォルト値: 3600

エージェント側のチェックアウトが使用されている場合の git fetch 操作のアイドルタイムアウト。 この間にフェッチプロセスからの出力がない場合、フェッチは終了します。

エージェント側チェックアウトルールの制限事項

Git プラグインは、 git sparse-checkout (英語) を使用してエージェント上の Git ファイルをチェックアウトします。 プラグインは、Git でサポートされる VCS チェックアウトルールのセットを制限する単純なファイルマッピング操作のみを実行できます。

次のルールがサポートされています。

+:dirA/dirA1 -:dirA/dirA1/dirA2 +:. => dirA/dirA1/dirA2 +:dirA => dirA +:dirA/dirA1 => dirA/dirA1 +:dirA/dirB/dirC => dirD/dirE/dirA/dirB/dirC

ルールはファイルを再マップしてはならないことに注意してください。 つまり、次のルールは サポートされていません: +:dirA/dirA1 => dirA/dirA2

1 つのルートに複数のチェックアウトルールを指定する場合は、それらのチェックアウトディレクトリ (ルールの右側の部分) に共通の親ディレクトリ ([prefix/]) があることを確認してください。 エージェント側のチェックアウトではルール +:dirA => [prefix/]dirA のみがサポートされており、 [prefix/] はすべてのルールで同じである必要があります。

例:

+:dirA/dirB/dirC => [prefix/]dirA/dirB/dirC +:dirD/dirE/dirF => [prefix/]dirD/dirE/dirF

次のルール サポートされていません: +:dirA=>[prefix/]dirA/postfix に注意してください。 チェックアウトディレクトリパスに [/postfix] を追加し、構成の VCS チェックアウトモード が "エージェントで常にファイルをチェックアウト" に設定されている場合、新しいビルドを開始できなくなります。

チェックアウトディレクトリパスエラー

既知の課題

  • java.lang.OutOfMemoryError は、 TeamCity.Git.フェッチ.プロセス.最大.メモリ プロパティが指定されている場合にリポジトリからフェッチするときに適用されます。 TeamCity 2019.2 以降は、このプロパティを無効化し、自動メモリ管理を TeamCity に委譲する方法が推奨されます。

  • Windows サービスとして実行されている TeamCity はネットワークにマップされたドライブにアクセスできないため、そのようなドライブにある Git リポジトリを操作できません。 これを機能させるには、 teamcity-server.bat を使用して TeamCity を実行します。

  • JGit でストリームを使用してインフレーションすると、 OutOfMemoryError が防止されますが、時間がかかる場合があります（問題に関連する TW-14947(英語) の問題を参照してください）。 同様の動作に気付いた場合は、 TeamCity.Git.ストリーム.ファイル.しきい値.MB を増やしてみてください。 また、 OutOfMemoryError を防ぐために、TeamCity に割り当てる全体的なメモリ量を増やすことをお勧めします。

2026 年 9 月 11 日
CVSMercurial