TeamCity On-Premises 2024.03 Help

Git

TeamCity 对 Git 提供了开箱即用的支持。 Git 源代码控制支持 Azure DevOps Services（请参见下面的验证说明）。

此页面包含 VCS 根设置中 Git 特定字段的描述。
有关常见 VCS 根属性，请参见 此部分。

重要提示：

在服务器上进行 VCS 相关操作的原生 Git

TeamCity 现在可以将原生 Git 作为服务器上 Git 操作的默认选项。 切换到原生 Git 可以提高服务器上检查更改操作的性能，相比之下，此前使用的 JGit 实现方式性能要差。 它还解决了与大型 Git 仓库相关的一些问题。

在切换之前，请确保您的服务器机器上已安装 2.29 或更高版本的 原生 Git 客户端，并在 PATH 环境变量中指定了其可执行文件的路径。 或者，您可以通过 teamcity.server.git.executable.path 内部属性设置可执行文件的完整路径（无需重新启动服务器）。 在 Windows 上，记得在路径中使用双反斜杠。

要将您的 TeamCity 服务器切换到原生 Git，请转到 Administration | Diagnostics 并打开 Git 标签。 在此，您可以通过原生 Git 在服务器上的任何 VCS 根目录测试连接。 如果您选择测试所有的 VCS 根，TeamCity 将检查它们是否能通过 JGit 成功连接，然后通过原生 Git 测试它们的连接。 这项措施有助于确保在切换到本地 Git 后，您的所有管道都不会中断。 如果连接测试成功，您可以在您的服务器上启用本地 Git 支持。

一般设置

  • Fetch URL — 用于从仓库获取数据的远程 Git 仓库的 URL。

    您可以覆盖单个代理的获取 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 设置代理。 例如，以下规则允许代理使用 http://proxy.com/test/test.git URL，而不是原始的 https://example.com/org/test/test.git：

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

    请注意，VCS 根除了存储获取 URL 外，还存储访问仓库所需的认证设置。 因此，只有使用 匿名 或 私钥 认证模式的 VCS 根才会实际替换 fetch URL。 其他模式不能保证代理能够访问仓库（例如，为源 VCS 发布的可刷新 token 不会被托管代理接受）。

  • Push URL — 用于将通过 VCS 标签 构建功能创建的带注解的标签推送到远程仓库的目标远程 Git 仓库的 URL。 如果为空，则会使用获取 URL。

  • 默认分支 - 默认分支。 此处支持参数引用。 默认值为 refs/heads/master。

  • 分支规格 — 列出了分支名称的模式，这是支持 功能分支 所必需的。 除了默认分支外，匹配的分支也会被监控以检测是否有变动。 语法与检出规则相似： +|-：branch_name ，其中 branch_name 是特定于 VCS 的，即 Git 中的 refs/heads/ （带有可选的 * 占位符）。

  • 将标签用作分支 — 允许监视 / 检出 git 标签作为分支，使分支规范与标签名称以及分支匹配（例如， +|-:refs/tags/<tag_name>）。 默认情况下，标签会被忽略。

  • 用户名样式 — 定义了 TeamCity 报告 VCS 变更的用户名的方式。 更改用户名风格只会影响新收集的更改。 旧的更改将继续以收集更改时的活动样式进行存储。

  • Submodules—— 选择您是否想要忽略这些子模块，或者将它们视为源代码树的一部分。 子模块仓库应该不需要身份验证，或者使用与 VCS 根目录中配置的相同的协议并接受同样的身份验证。

  • 用于标签/合并的用户名 — 一个用于标签的自定义用户名。

分支匹配规则

  • 如果分支与没有模式的行匹配，那么将使用该行。

  • 如果分支与几行模式相匹配，将使用最佳匹配行。

  • 如果有几行匹配相等，下面的一行优先级最高。
    通配符匹配到的所有内容将在 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）

验证设置

  • 匿名 — 选择此选项以匿名读取访问权限克隆存储库。

  • 密码/个人访问令牌 — 指定一个有效的 用户名 (如果克隆 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 访问的存储库中将 Code 访问范围设置为 Code （读取）/ Code （读取和写入）用于版本设置。

    在使用现有的 Bitbucket Cloud、Bitbucket Server、GitLab 或 Azure DevOps Services 连接创建 VCS Root 时，TeamCity 将使用可刷新的令牌，而非密码。

  • 可刷新令牌 — 如果一个从 GitHub、GitHub App、Bitbucket Server、Bitbucket Cloud、Azure DevOps、GitLab 或 JetBrains Space 获取数据的 VCS 根通过 TeamCity 连接进行配置，那么默认启用可刷新令牌。 这样的令牌寿命较短，提供的安全性比密码或个人访问令牌更强：TeamCity 服务器会自动刷新它们，而不与代理共享任何相关数据。

    Token 字段显示了获取令牌的用户和提供令牌的连接的信息。

    如果克隆URL中没有username，您可以在这里指定一个。在此处指定的用户名将覆盖URL中的用户名。

    对于 Azure DevOps 、 GitHub App 、 Bitbucket Server 、 Bitbucket Cloud 、 JetBrains Space 和 GitLab 连接，您可以点击 获取新的 按钮，以用当前用户的令牌立即重新签发 VCS 根所使用的令牌。

    重新发行令牌

  • 私钥 — 仅适用于 SSH 协议。 私钥必须采用 OpenSSH 格式。

    从 Private Key 列表中选择一个选项，并指定一个有效的用户名（如果克隆 URL 中没有用户名；此处指定的用户名将覆盖 URL 中的用户名）。
    可用的 Private Key 选项：

    • 上传的密钥 — 选择此选项以使用上传到项目的密钥。

    • 默认私钥 — 选择此选项以使用文件系统中默认位置的可用密钥，这是常用 ssh 工具的默认位置：如果文件存在或私钥文件 <用户主目录>/.ssh/id_rsa （需要在服务器上并且在使用 代理端检出的代理上）则按照 <用户_主页>/.ssh/config 中指定的映射。

    • 自定义私钥—— 仅支持用于服务器端检出。 在服务器机器上，将Private Key Path字段填写为私钥文件的绝对路径。 如果密钥已加密，请在相应的字段中指定口令。

要查看连接到 GitHub 的所有可用选项，请参见 评论。

向 Azure DevOps 服务进行身份验证

如果您在 Azure DevOps Services 中使用 Git 源代码控制，您可以同时使用 Azure DevOps OAuth 和 Azure DevOps PAT 连接。

服务器设置

这些是在服务器端 checkout 的情况下使用的设置。

选项

描述

将行结束符转换为 CRLF

将所有文本文件的行结束符转换为 CRLF（在仓库配置中设置 core.autocrlf=true 同样有效）。 当未被选中时，不会执行行尾转换（等同于设置 core.autocrlf=false）。 仅影响服务器端的检出操作。 对此属性的更改会导致一次全新的签出操作。

代理设置

这些是在代理端 checkout 的情况下使用的设置。
请注意，代理端 checkout 对 SSH 的支持有限。 唯一支持的身份验证方法是 "Default Private Key" 和 "Uploaded Private Key"。
如果您计划使用 代理端签出（agent-side checkout），则需要在代理上安装 Git 1.6.4+。

选项

描述

Git 的路径

请在代理上提供要使用的 Git 可执行文件的路径。 当设置为 % \ env . TEAMCITY_GIT_PATH % 时，将使用自动检测到的 Git，请查看 代理上的 Git 可执行文件 以获取详细信息。

签出政策

这个设置定义了 TeamCity 如何向构建代理进行检出。

  • 使用镜像：建议用于寿命较长的代理。 选择此选项后，TeamCity 会在代理机器的 system/caches/git 目录下创建一个远程仓库缓存。 缓存随后会作为 替代项 添加，以便更新 构建检出目录。 为了加快此存储库的后续检出速度，代理将在所有具有相同取件 URL 的构建中复用缓存。 这也可以加快清理检出的速度（因为只有 建工作目录 是被清理的），并节省磁盘空间（因为镜像是该代理上给定存储库的唯一克隆）。

  • 不要使用镜像：选择直接检出到 构建检出目录，而无需创建镜像。 在磁盘使用方面不如镜像优化，但为了与现有配置保持向后兼容而保留。

  • Shallow clone：建议用于生命周期较短的代理；例如，用于每次构建后就终止的一次性云代理。 通过仅获取一个所需的修订版本，创建一个浅克隆，从而在构建开始时节省时间。 只有在您的构建中不需要 Git 提交历史记录，且您的云镜像中不存在新的 Git 镜像时，才选择此选项。 您可以通过指定 teamcity.git.shallowClone=true 代理配置属性 来强制在某些代理上应用此选项。

  • Auto：TeamCity 将根据 teamcity.cloud.agent.terminate.after.build agent configuration property 和 agent 上是否存在镜像自动应用上述方法之一。

清理策略 / 清理文件策略

在此处指定 git clean 命令在代理上运行的时间，以及需要删除的文件。

如果构建配置依赖于多个 VCS 根，我们建议您为每一个根配置独立的代理检出目录，使用 VCS 检出规则。 这样， git clean 在清理过程中永远不会删除这些检出目录。

代理上的 Git 可执行文件

TeamCity 需要在 agent 上使用版本 1.6.4+ 的 Git 命令行客户端，以便使用 代理端签出（agent-side checkout）。

推荐的方法是确保 git 客户端在 TeamCity 代理的 PATH 中是可用的，并且在 VCS 根设置中留空 "Path to git" 。
如果您只在一些机器上有 git 命令行，将 VCS 根的 "Path to 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\bin

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

    • C:\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 根 设置中的 Path to git 字段中使用。 因此，只有在检测到或在代理属性中指定了 Git 的情况下，该配置才会在这样的 VCS 根的代理上运行。

在云代理上的 Git 镜像

默认情况下，TeamCity 会在代理的 system / git 目录下创建一个 镜像，即您的 Git 仓库的副本。 为了节省获取源文件的时间和磁盘空间，TeamCity 在更新构建的检出目录时，通过 Git 替代机制指向这个镜像。

与自托管的 TeamCity 代理相比，云代理需要额外的步骤来添加 Git 镜像：

  1. 在准备云镜像 时，将仓库克隆到代理镜像的 system / git 目录下。 如果需要，您可以并排存储多个 *.git 目录。

  2. 在 system / git 目录下创建一个 映射 文件，并描述原始仓库和其镜像之间的映射关系。 例如，

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

当开始构建时，云代理将检查在 映射 文件中指定的镜像，并获取所需来源与其镜像之间的差异。 映射 文件中的起始 URL 必须与 VCS 根中设置的 URL 相匹配。
这样，构建将运行得显著更快，无需每次新的云代理启动时检出整个远程仓库。

在服务器上配置 Git 垃圾回收

TeamCity 服务器为服务器上配置的每个 VCS 根中使用的 Git 仓库维护一个本地克隆。 由于服务器每天都会在这些克隆中多次执行 fetch 操作，因此克隆需要定期优化以保持可预测的性能。 如果克隆的 Git 垃圾收集长时间未运行，收集更改的过程可能会变慢或开始报告与内存相关的错误。
如果可以在服务器上找到本地 Git 客户端，TeamCity 可以自动周期性运行 git gc。 无法运行 Git GC 导致相关的健康报告出现问题。

为了解决警告 / 满足自动 git gc 的要求，执行以下操作：

  1. 在 TeamCity 服务器上手动安装本地 Git 客户端。

  2. 指定 Git 可执行文件的路径：

    • 将可执行文件的目录添加到 PATH 环境变量中，并重新启动服务器，或者

    • 在不重新启动服务器的情况下，将可执行文件的完整路径设置到 teamcity.server.git.executable.path 内部属性 中。 在 Windows 上，记得在路径中使用双反斜杠。

当 TeamCity 运行 Git 垃圾收集时，详情将记录在 teamcity-cleanup.log 中。 如果 git 垃圾收集失败，将显示相应的警告。

TeamCity 运行 Git 垃圾收集，直到总时间不超过 5 小时配额；配额可以使用 teamcity.server.git.gc.quota.minutes 内部属性。
Git 垃圾收集每天凌晨 2 点执行。 您可以通过指定内部属性并像这样使用cron表达式来进行更改： teamcity.git.cleanupCron=0 0 2 * * ?。 如果 git gc 进程运行缓慢，无法在规定的时间内完成，请检查默认 Git 配置文件中的 git-repack 配置（例如，您可以增加 --window-memory 来提高 git gc 的性能）。

如果本地 Git 克隆需要某种手动维护，您可以在 <TeamCity 数据目录>/system/caches/git 目录下找到它们。 目录中的 映射 文件包含了存储库 URL 和存储存储库空克隆副本的子目录之间的映射关系。

LFS 和 Submodules 支持

常见信息

子模块和 LFS 是许多复杂软件产品的重要组成部分，这些软件产品的源代码存储在基于 Git 的版本控制系统中。

  • Submodules 允许您将 Git 仓库保持为其他 Git 仓库的子目录。 例如，您可能希望在您的组织中包含由另一团队开发的微服务，或者您的代码依赖的第三方开源项目。 因此，您可以将一个仓库克隆到您的父项目中，同时保持提交记录的独立。

  • Large File Storage (LFS) 允许您通过将大型文件（媒体文件、数据库等）移至外部存储，并用指针替换这些文件，从而大幅减小您的仓库大小。

尽管在使用场景和实施机制上有所不同，但这两种概念都建议从外部源（托管在远程 LFS 服务器上的文件或 VCS 中的另一个存储库）中引入项目的必要组件。 这意味着您的 TeamCity 项目需要验证不同的资源以检出源文件。

附加凭据

如果您的版本库导入了托管在同一版本控制系统上的子模块，并且这些被导入的版本库可以通过存储在您的 VCS Root（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

  • <ALIAS> 是一个自定义字符串，用于将您的 teamcity.git.https.credentials... 属性分组成三个一组，并用于识别必需的属性。 例如，如果您的 GitHub 仓库需要从 Sonatype Nexus LFS 导入大文件，并从 Azure DevOps 导入额外的子模块，您将需要六个属性。 他们中的三个可以有 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/lfs。 SSH 协议目前不受支持。

  • 用户名 和 密码 用于存储相应服务的凭证。 请注意，正常访问常规仓库时生效的所有限制和指南也适用于 LFS / submodule 的检出。 例如， ...密码 属性应储存访问令牌，而非常规帐户密码，因为大多数 Git 托管服务正在持续停用后者选项。 ...用户名 属性也应存储一个可与访问令牌一起使用的值（例如，GitHub 和 GitLab 的常规帐户名称，或者 Bitbucket Cloud 的 "x-token-auth"）。 另请参阅：

限制和建议

  • 应为 TeamCity 项目配置用于存储额外凭证的配置属性，而不是构建配置。

  • 出于安全原因，将所有 ...密码 参数切换为 密码类型。 这将确保您的令牌和密码对 TeamCity UI、构建日志、Kotlin DSL 和 REST API 负载保持隐藏。 另外，我们建议启用 只读 设置针对 teamcity.git.https.credentials.<ALIAS>.url 参数，以防止潜在的攻击者编写他们自定义的 URL 到这个参数并窃取您的授权令牌。

    秘密类型和只读属性

  • 我们建议您使用 Git LFS 版本 2.12.1 或更高版本，因为早期版本存在漏洞利用问题。

  • TeamCity 只支持 代理端签出（agent-side checkout） 的 Git LFS。

  • 当前，只有通过安全的 HTTPS 协议才能访问子模块仓库和 LFS 文件。 SSH 和 HTTP 协议不受支持。

内部属性

对于 Git VCS，可以配置以下 内部属性：

属性

默认

描述

teamcity.git.idle.timeout.seconds

1,800

与远程仓库通信的空闲超时。 如果在此超时期间未发送或接收任何数据，插件会抛出一个超时错误，以防止进程永远挂起。

teamcity.git.fetch.timeout

1,800

（已弃用）对于 git fetch 操作的 teamcity.git.idle.timeout.seconds 重写

teamcity.git.fetch.separate.process

true

定义 TeamCity 是否在单独的进程中运行 git fetch

teamcity.git.fetch.process.max.memory

这个属性提供了明确的 -Xmx 并禁用了自动 -Xmx 设置。

确保服务器机器具有足够的内存，因为配置的内存将被用作主服务器进程的补充，且可能存在执行 git fetch 和 git patch 的多个子进程，每一个子进程都将使用配置的内存量。 对于需要大于 -Xmx1024m 堆内存的大仓库，可能需要切换到 64 位 Java。

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

默认情况下，TeamCity 会为 git fetch 和 git patch 启动嵌套的 Java 进程，并自动为这些进程选择 -Xmx。

这个属性规定了 TeamCity 可以自动设置的 -Xmx、 git fetch 或 git patch 的最大可能值。

teamcity.git.monitoring.expiration.timeout.hours

24

teamcity.server.git.gc.enabled

false

在服务器清理过程中，TeamCity 是否应运行 git gc （使用的是原生 git）

teamcity.server.git.executable.path

git

服务器上本地 git 可执行文件的路径。 在 Windows 上，记得在路径中使用双反斜杠。

teamcity.server.git.gc.quota.minutes

60 位

运行的最大时间量 git gc

teamcity.git.cleanupCron

0 0 2 * * ? *

Cron 表达式 用于 git-plugin 中清理的时间， 默认情况下 —— 每天凌晨2点。

teamcity.git.stream.file.threshold.mb

128

在 JGit 使用流来膨胀对象后的阈值（以兆字节为单位）。 如果您的代码库中有大型二进制文件，并且看到了在 TW-14947 中描述的症状，那么请增大此值。

teamcity.git.buildPatchInSeparateProcess

true

Git-plugin 在一个独立的进程中构建补丁，将其设置为 false 以在服务器进程中构建补丁。 为了构建补丁，git-plugin 需要将存储库文件读入内存。 为了避免内存耗尽，git-plugin 只读取小于阈值大小的对象，对于大对象，用的是流，可能会慢 （TW-14947）。 在单独的进程中进行补丁构建，所有对象都会被读入内存。 补丁进程使用单独取回进程的内存设置。

teamcity.git.mirror.expiration.timeout.days

7

未使用的存储库副本在服务器机器上被移除后的天数。 如果没有对此仓库进行 TeamCity 操作，例如检查更改或获取当前版本，那么该仓库被视为未使用。 这些操作非常频繁，所以 7 天是一个相当高的值。

teamcity.git.commit.debug.info

false

定义是否在找到的每个提交上记录额外的调试信息。

teamcity.git.repackIdleTimeoutSeconds

1,800

定义 git-repack 操作的空闲超时时间，单位为秒。 对于大型仓库，您可能需要增加此超时时间，因为在其中重新打包对象需要很多时间。

teamcity.git.sshProxyType

SSH 代理类型，支持的值包括： http、 socks4、 socks5。 请注意，socks4 代理无法解析远程主机名，因此，如果您收到 UnknownHostException，可以选择切换到 socks5，或者在 TeamCity 服务器机器的 hosts 文件中为您的 git 服务器添加一个条目。

teamcity.git.sshProxyHost

SSH 代理主机

teamcity.git.sshProxyPort

SSH 代理端口

teamcity.git.connectionRetryAttempts

3

尝试建立与远程主机的连接以进行连接测试和获取当前存储库状态的次数，然后才承认失败

teamcity.git.connectionRetryIntervalSeconds

4

连接尝试之间的秒数间隔

构建参数适用于 Git：

属性

默认

描述

teamcity.git.use.native.ssh

false

在代理上进行检出时：TeamCity 是否应使用本地 SSH 实现。

teamcity.git.idle.timeout.seconds

3600

当使用代理端检出时， git fetch 操作的空闲超时。 如果在此期间取回过程没有输出，那么取回就会被终止。

Agent 端签出规则限制

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。

如果您为一个根目录指定了多个检出规则，请确保它们的检出目录（规则的右侧部分）有一个共同的父目录（ [前缀/]）。 仅支持代理端签出的规则 +:dirA => [prefix/]dirA ，而且所有规则的 [前缀/] 必须相同。

例如：

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

请注意，以下规则 不受支持： +:dirA=>[prefix/]dirA/postfix。 如果您在检出目录路径后添加 [/后缀] ，并且配置的 VCS 检出模式 设为 "始终在代理上检出文件"，则新的构建将无法启动。

签出目录路径错误

已知问题

  • java.lang.OutOfMemoryError 从仓库中获取时，如果指定了 teamcity.git.fetch.process.max.memory 属性，则可能存在问题。 自 TeamCity 2019.2 起，建议的做法是禁用此属性，从而将自动内存管理委托给 TeamCity。

  • 作为 Windows 服务运行的 TeamCity 无法访问网络映射驱动器，因此您无法使用位于此类驱动器上的 git 仓库。 为了使其运行，使用 teamcity-server.bat 运行 TeamCity。

  • 在 JGit 中使用流进行膨胀可以防止 OutOfMemoryError ，但可能会耗费大量时间（参见与此问题相关的 TW-14947 问题）。 如果您注意到类似的行为，请尝试增加 teamcity.git.stream.file.threshold.mb。 另外，建议增加为 TeamCity 分配的总内存量，以防止 OutOfMemoryError。

最后修改日期： 16日 7月 2024年
CVS SSH 密钥管理