已知问题
这个页面包含了一份关于 TeamCity 已知问题的解决方案列表。
要查看针对 TeamCity 特定版本的问题，请前往 升级说明 的相应部分。
与 JDK 8 更新版 242+ 不兼容
在 JDK 8u242+ 下运行的 TeamCity 版本最高可达 2019.2.1，可以报告 java.lang.NoClassDefFoundError：无法初始化类 XXX 错误，例如，在 Git 操作或 Windows 域认证操作上。
在 TeamCity 2019.2.2 发布之前，建议您使用 Java 8u232 版本进行 TeamCity 服务器。
作为 Windows 服务运行的 Agent 限制
当 TeamCity 构建代理安装为 Windows 服务时，在构建过程中可能出现各种"权限被拒绝"或"访问被拒绝"的错误，具体详见以下内容。
Windows 服务的限制
作为 Windows 服务，TeamCity 代理和构建过程无法访问网络共享和映射驱动器。
为了克服这些限制，运行 TeamCity 代理 通过控制台。
关于自动化 GUI 和浏览器测试的问题
这些问题包括无头运行测试的错误，TeamCity 代理与 Windows 桌面交互的问题等等。
为了解决/避免以下问题：
运行 TeamCity 代理 通过控制台。
配置构建代理机器不启动锁定桌面的屏保。
将 TeamCity 代理配置为自动启动（例如，在 Windows 启动时配置自动用户登录，然后在用户登录时（通过
agent.bat start）配置 TeamCity 代理启动）。
对于图形测试，构建代理不能作为服务启动，建议在用户自动登录后的1分钟后配置构建代理启动，例如，使用任务调度程序中的 bin\agent.bat start 命令并在那里配置延迟。
运行自动化 GUI 测试并使用 RDP
RDP 使用其自身的视频驱动程序来覆盖会话中机器视频卡的驱动程序。 将会话重定向到控制台将卸载 Windows 图形驱动程序。 您可以通过在进行测试之前，向您的构建配置中添加以下步骤来实现这一点（下面的示例是用于 PowerShell 的，但也可以使用其他语言（如 DOS，Python））：
在这里 quser [当前用户名] 列出了用户对该机器的所有连接，无论是控制台还是图形界面。
被列为 rdp-tcp#* 的是远程桌面连接，可以使用 tscon [连接 id] /dest:console 重定向到控制台。
.NET Selenium 出现的问题
当 TeamCity 代理作为 Windows 服务启动，并且 .NET 应用程序的自动化测试使用 Selenium WebDriver 时，由于浏览器驱动器的限制，测试可能会失败。 作为一种解决方案，考虑手动启动代理 manually。
在初始化其他资源之前提前启动服务
为了处理这个问题，可以考虑使用服务设置的 自动（延迟启动） 选项，或者配置 服务依赖性。
要了解更多的调查步骤，请查看 常见问题 页面。
java.lang.OutOfMemoryError：无法创建新的本地线程错误
如果您的 TeamCity 服务器运行在 SUSE® Linux 企业版（或者使用 systemd Daemon）上，java.lang.OutOfMemoryError: unable to create new native thread error可能是由于cgroup 进程数量控制器的特性导致的，该特性默认限制了一个 cgroup 中的进程数量和线程数量为 512。
在 TeamCity 服务器上增加限制（例如，增至 4096）应该可以解决此问题。
也可以参阅这个 外部发布。
清除浏览器缓存
一些用户遇到了与网络界面相关的问题（其他计算机无法复现该问题），这与缓存版本的内容有关。 如果您遇到了此类问题，请确保您的浏览器未使用内容的缓存版本，方法是清除浏览器缓存。
在您的测试中使用 Log4j 进行日志记录
如果您在测试中使用 Log4j 记录，那么在某些情况下，您可能会错过来自您日志的 Log4j 输出。 在这种情况下，请按照以下步骤操作：
使用 Log4j 1.2.12
对于 Log4j 1.2.13+，在 Log4j 配置中使用的控制台追加器中添加
遵循=true参数：<appender name="CONSOLE" class="org.apache.log4j.ConsoleAppender"> <param name="Follow" value="true"/> </appender>
在 Windows x64 下，用户登出时Agent Service可以退出
使用的 Java Service Wrapper 版本并未完全支持 Windows 64 ，这导致用户注销时，代理启动器进程被终止。 代理本身将一直运行，直到下一次重启（服务器升级或代理属性更改）。
使用 Maven 2.0.7，失败的构建可以被报告为成功的
这是 Maven 当前版本中的一个已知错误。 请考虑使用任何较新的版本。
如果无法做到，您可以通过替换 mvn.bat 中第 148 行的片段来自行修补 mvn.bat。
与以下内容一致：
冲突的软件
最常见的冲突软件指示符是像“拒绝访问”，“权限被拒绝”或java.io.FileNotFoundException这样的错误，其中提到了存在且可以由代理/构建运行的用户写入的文件。 另外，某些在后台运行的软件（如杀毒软件）可能会大大降低构建代理操作的速度，例如源代码签出、构件发布甚至构建运行。
某些防病毒软件，如 Kaspersky Internet Security，可能会导致 Java 进程崩溃或产生其他异常行为，例如无法访问文件。 例如，查看 此问题。
ESET 防病毒软件也可能大大降低 Ant / IntelliJ IDEA 项目构建的速度（减慢代理上 localhost 的 TCP 连接）。
如果您在 TeamCity 服务器或代理机器上运行防病毒软件，并且出现磁盘访问错误或性能下降，您可能会考虑在调查问题和向 JetBrains 报告之前暂时禁用防病毒软件。 请注意，禁用防病毒软件可能会使您的设置更容易受到潜在的外部攻击，所以在做此操作之前，请确保您已采取适当的安全措施。
我们建议在后台检查中排除整个 TeamCity 服务器主目录和 TeamCity 数据目录，并在公认的维护窗口中定期进行检查，以便这些操作不会过多地影响服务器性能。 在 TeamCity 代理上，建议从背景检查中排除 TeamCity 代理安装目录。
可能存在与 Windows 索引服务相关的问题，因此请禁用各种索引服务。 请参阅 相关问题 获取更多详情。 可能还需要禁用 Windows 系统还原功能。
不要安装带有后台索引功能的软件，如 WinCVS 、 TortoiseCVS 、 TortoiseSVN 、以及其他 Tortoise* 产品。 这适用于服务器，如果您使用代理端检出，也适用于代理。
众所周知，Skype 软件会破坏在 Internet Explorer 中显示的页面布局。 （TW-13052）。
Subversion 问题
svn：E175002：收到致命警告：bad_record_mac
在构建服务器上添加系统属性 -Dsvnkit.http.sslProtocols=SSLv3,TLS （参见 配置 TeamCity 服务器启动属性）。
如果您在 agent 上使用 checkout，则还需在构建 agent 上添加此属性 在构建 agent 上。
与 Subversion 相关的 JVM 崩溃
如果在执行与 SVN 相关的代码时（例如在 org.tmatesoft.svn 包下），JVM 崩溃，您可以尝试使用以下选项之一来禁用它：
将
-Dsvnkit.useJNA=falseJVM 选项传递给崩溃的进程（服务器或代理）通过传递
-Dsvnkit.http.methods=Basic,Digest,NTLMJVM 选项，降低 NTLM 支持的优先级。
无论如何，我们推荐将使用的 JVM 升级到最新可用版本。
NUnit 2.4.6 性能
由于 NUnit 2.4.6 中的一个问题，它的性能可能会比 NUnit 2.4.1 慢。 如需更多信息，请参考我们问题跟踪器中对应的问题：TW-4709
StarTeam 性能
在 TeamCity 服务器上使用 StarTeam SDK 9.0 替代 StarTeam SDK 9.3 可以在 TeamCity 和 StarTeam 服务器之间的连接速度较慢时，显著提高 VCS 的性能。
Perforce 2009.2 在 Windows 上的性能
如果您在 Windows 上运行 Perforce 2009.2 ，您可能会经历显著的速度减慢。 这是一个在 Windows 上运行的 P4 服务器出现的问题。 参考 Perforce 文档中相应的 部分。
构建计划触发的错误时间（时区问题）
请确保您使用针对您的平台的最新 Java 8 安装更新（例如，由 Amazon Corretto 提供的 OpenJDK 8）。
升级 IntelliJ IDEA 可能会影响活动的预测试提交
在您升级到 IntelliJ IDEA X （或其他 IntelliJ X 平台产品）之前，确保您没有活动的预测试提交，否则升级后将无法提交。 如果您使用基于目录的 IDEA 项目（项目文件存储在 .idea 目录下），这只是相关的。
在同一服务器上运行的其他 Java 应用程序
如果同一主机名下还有其他可用的网络应用，可能会出现会话cookie冲突。 这通常表现为随机用户登出或丢失会话级数据。 （例如，TW-12654）。 为了解决这个问题，您可以在访问应用程序时使用不同的主机名。
服务器无法启动，声称数据库正在使用中
只有一个 TeamCity 服务器可以与一个数据库一起工作，这在 TeamCity 服务器启动时进行检查。
"在以下任何一种情况下，都会报告" 数据库正在使用中 "在启动时出现错误：
尝试启动多个连接到同一数据库的 TeamCity 服务器
检测到第二个 TeamCity 实例
内部的 HSQL 数据库正在被另一款应用程序使用
错误很可能是由于另一个正在运行的 TeamCity 安装连接到了同一数据库所导致的。 请检查数据库属性是否正确，确保没有其他的 TeamCity 服务器使用相同的数据库。
从 TeamCity 服务器下载速度慢
如果您在从 TeamCity 下载构件时遇到下载速度慢的问题，尝试在服务器机器上检查速度，从 localhost 下载。 如果 localhost 的速度可以，那么问题可能出在网络配置或者操作系统 / 硬件设置上，当它们与 TeamCity（Tomcat）设置结合时。
确保 <TeamCity 安装目录>\conf\server.xml 文件对应于包含在 TeamCity 发行版中的文件（可以在 .tar.gz 发行版中进行检查）。 如果您有以下的 "Connector" 节点（端口号可能会有所不同）：
将其更改为：
并重新启动 TeamCity 服务器。
如果这对下载速度没有帮助，为了调查此问题，您可能需要找到一位具备适当网络相关问题调查技能的管理员来研究这个案例。
IIS 相关问题
无法将构件发布到位于 IIS 反向代理后的服务器
此问题仅与涉及在构建服务器和代理服务器之间的 IIS 反向代理的配置相关。 有时，构建代理可能会陷入无限循环，试图将构建工件发布到服务器上。 构建日志如下所示：
与此同时， teamcity-agent.log 充满了 IIS 产生的 404 响应：
这种情况最常见的原因是 maxAllowedContentLength 设置（在 IIS 中）要么
设置为过小的值，或者
留空未配置，因此默认为30000000字节（<30 Mb）
因此，任何大于 maxAllowedContentLength 的工件都会被 IIS 丢弃。请检查设置值，并尝试重新运行您的构建。
在使用 IIS 的设置中，Artifacts 域隔离会导致访问 artifacts 时出现授权错误
如果您的 TeamCity 服务器启用了 Artifacts Domain Isolation，尝试访问构建工件可能会导致 401 未授权错误。 这个问题很可能是由于您的 IIS 网络服务器的默认行为所引起的：它将目标从构件的域重新写回到主服务器域的响应头。 要禁用此行为，请转到 IIS 界面中的 应用程序请求路由 | 服务器代理设置 ，并禁用 "在响应标头中反向重写主机" 选项。
TeamCity UI 中缺失的内容
在加载 TeamCity 页面时，您可能会注意到一些内容缺失。 通常，已完成构建的构建配置不会显示其构建历史，看起来是空的。 与此同时，网络浏览器记录了多个 404 （未找到）错误。
如果这种情况发生在运行在 IIS 服务器上的 TeamCity 实例上，请检查 IIS 的 maxQueryStringLength 和 / 或 maxQueryString 的值。 这些设置限制了查询字符串的最大长度。 如果这些限制太低，TeamCity 发送到 <服务器网址>/app/rest/... 端点的一些 REST 请求可能会失败。
要解决此问题，您需要在 IIS 服务器的 web.config 文件中提高这些限制。 精确的值应取决于您当前的配置和您的项目/配置 ID 的长度。 一般来说，建议您将此限制设置为4000个字符，如果问题仍然存在，则逐渐提高它。
另见：请求限制 | httpRuntime 元素
在从 TeamCity 连接到 HTTPS 时出现 SSL 问题（握手警告：unrecognized_name）
当从 1.6 切换到 1.7 的 JVM 并连接一些配置不正确的 HTTPS 服务器时，可能会出现这个问题。 问题和解决方法在 此问题 中进行了描述。
在重装 Agent 时配置窗口扭曲
当在已经安装了不同版本 Java 的代理上通过 Windows 代理安装程序 安装一个 TeamCity 代理时，"配置构建代理属性" 安装窗口可能会显示扭曲。
此问题已在 TeamCity 2019.1.5 中得到修复。
为了解决此问题，而无需升级至 2019.1.5 ，请在同一目录中安装新代理程序前，卸载已安装的先前版本代理程序。
若要卸载代理程序，请在 代理主目录 中调用 Uninstall.exe ，清除所有 "移除..." 的复选框以保留代理日志和配置，然后点击 卸载。 成功卸载后，您可以通过代理安装程序继续安装新的代理版本。
Windows 中的 TeamCity 服务器版本不正确
自动的 TeamCity 更新可能无法将新版本号写入相关的 Windows 注册表键。 这会使标准的 Windows 添加或删除程序应用程序显示最初的 TeamCity 安装版本，该版本在更新后从不改变。
要手动更新注册表键并设置正确的版本，请按照 TeamCity 管理员 | 更新 页面上的说明运行与您的 TeamCity 安装包一同提供的 PowerShell 脚本：
Windows Docker 容器
与 TeamCity Docker 容器镜像相关的常见问题。
自从 Windows 10 版本 1803 配合 KB4340917，就可以从容器中使用端口映射到 localhost。 对于以前的 Windows 版本，此机器关联的非本地主机 IP 地址有效，您可以通过机器的主机名访问正在运行的应用程序，或者通过
ipconfig命令确定 IP 地址。 请注意，netstat -an命令可能无法显示端口在任何 IP 地址上是否打开，尽管事实上它可以工作。 这也是 Docker 在 Windows 上的一个已知问题。在 Windows 10 上，默认为每个容器分配 1GB 内存。 要增加此值，请使用以下内存选项：
docker run ... -m 6GB --cpus=4 -e TEAMCITY_SERVER_MEM_OPTS="-Xmx3g -XX:ReservedCodeCacheSize=640m"在 Windows 10 中，容器通过 Hyper-V 运行，可能会遇到网络和其他子系统的问题。 要诊断这些问题，请执行以下的 PowerShell 脚本：
Invoke-WebRequest https://aka.ms/Debug-ContainerHost.ps1 -UseBasicParsing | Invoke-Expression当从 Windows Docker 镜像启动 TeamCity 服务器时，请确保向“经过认证的用户”授予对用作卷的目录的完全控制权限。 请参阅相关问题。
当使用目录
C:/BuildAgent/work作为映射到容器主机的卷来启动 Windows Docker 容器时，Git for Windows 会出现以下错误：" 无效路径 '/ContainerMappedDirectories'：没有此类文件或目录"。 解决方法是不要将C:/BuildAgent/work添加为一个卷。
要分析脚本输出，请参阅以下文档。 如果显示出容器网络子系统存在问题，尝试使用 clean-up scripts 进行重置。
有关 Windows 的 Docker 故障排除的更多细节在 Docker 和 Microsoft 的文档中都有提供。
关于在 Windows 上安装的 Docker 服务器操作系统的信息在 Agent 上缺失
在 Windows 10 上，Docker 服务器依赖于 Hyper-V 服务，其启动可能需要大量的时间。 为了解决这个问题，请将 TCBuildAgent Windows 服务配置为依赖于 Docker for Windows 服务， com.docker.service 默认。
在 Windows 下的 Linux Docker 容器
容器包装器 在启动 Windows-based 容器时可以在 Windows 上运行。
如果在 Windows 机器上启动了 Linux 容器，TeamCity 将显示错误消息 "在 Windows 下启动 Linux Docker 容器是不支持的。 为了避免这个问题，添加的 teamcity.agent.jvm.os.name 不包含 Windows 代理要求。
如果您需要支持在 Windows 平台下运行 Linux 容器的使用情况，容器包装器 请为 TW-51820 中的相关评论投票。
Windows 容器中的本地时间问题
在使用 Windows Docker 容器时，存在一个问题，即当容器中的系统时间与主机机器上的时间不同步时，Windows 容器中的时间错误。 在响应时间非常关键的集成中（例如，OAuth tokens），可能会引发问题。
为了解决这个问题，您需要将主机升级到 Windows Server 2019 / Windows 10 1809，并使用与 Windows 容器 1809兼容的 TeamCity docker 镜像。
"拒绝访问"或"路径访问被拒绝"在容器启动时出现问题
当 Docker 以 进程隔离 的方式启动 Windows 容器时，它使用的 Windows 用户帐户缺少向 Docker 卷目录写入的权限。 在这种情况下，由于“Access to the path is denied”或“Access is denied”错误，构建代理可能无法启动。
为解决此问题，您需要在 docker run 命令中为 ..\TeamCity\temp 目录指定一个专用的卷映射。 我们也建议确保为此过程分配了足够的资源。
或者，您可以为 %PROGRAMDATA%\docker\volumes 目录授予 "Authenticated Users" 组 "Full control" 权限。
dotCover 已知问题
dotCover 不支持 Windows Nano Server
如果您尝试在带有 Nano Server OS 的代理上运行 dotCover，构建将以退出错误“Process exited with code -1073741515”失败。 与其使用 Nano Server，不妨考虑使用 Server Core，它是 Windows Server 的另一种最小化安装选项。
dotCover 不支持 msbuild 的覆盖率统计
dotCover 不支持收集 dotnet msbuild /t:vstest 命令的覆盖率统计信息，请改为使用 dotnet test。
使用 Test Settings 进行代码覆盖率配置已被弃用
在 dotCover 中，使用测试设置进行代码覆盖率配置已被弃用。 在 Microsoft 文档中阅读更多内容。
如果您使用 .testsettings 文件，TeamCity 将在日志中显示警告信息。 为了防止这个问题，我们建议您使用 .runsettings 文件代替。 如果因为某些原因，您必须继续使用 .testsettings ，请在 TeamCity 代理上安装 2019.1.x 或更早版本的 dotCover，如此处所述。
Xcode 10 无法清理自定义输出目录中的构建工件
如果您使用自定义输出目录为 Xcode ，请注意在升级到 Xcode 10 后，使用 Xcode 项目构建运行程序的 TeamCity 构建可能会因错误而失败："无法删除 <directory>，因为它不是由构建系统创建的，也不是派生数据的子文件夹。
这是由以下 Xcode 10 已知问题引起的：
当在一个使用了自定义构建位置（位于派生数据目录外）的项目上执行 xcodebuild clean ，并且该项目具有在 Xcode 10 之前生成的旧构建产品时，Xcode 可能会报告一个错误，表示它不会删除未由新构建系统创建的目录。 (40427159)
请参阅 Xcode 文档 以获取详细信息。
为了解决这个问题，我们建议您使用 Xcode 11。 为了解决 Xcode 10 中的这个问题，您可以手动清理输出目录，或尝试通过向命令行参数传递 -UseNewBuildSystem=NO 来使用前一种构建系统。
跨服务器项目" 弹出菜单可能无法在最新的浏览器中正常工作
由于最近在 SameSite cookie 支持上的更新，项目 弹出菜单可能无法在一些最新的网页浏览器中显示 跨服务器项目（请参阅 Chrome 平台的 更多详情）。
如果您无法访问跨服务器的 Projects 菜单，您可以尝试临时解决此问题，方法是更改您的浏览器设置：
在 Google Chrome 中，打开
chrome://flags页面并禁用 "SameSite by default cookies" 选项。在 Mozilla Firefox 中，打开
about:config页面并禁用network.cookie.sameSite.laxByDefault选项。在 Safari 中，请转到 偏好设置 | 隐私，并禁用 "阻止跨站点跟踪" 选项。
这个问题将在 TeamCity 2020.1.5 更新中得到解决。 请查看 相关问题 以获取更多细节。
.Net 运行器 已知问题
.NET 运行器与过时的外部 .NET CLI Support 插件不兼容
重新设计的 .NET 构建运行程序 与过时的外部插件 .NET CLI Support（在 2017.1 及更早版本中使用）不兼容。 如果您的服务器上安装了过时的插件，那么在更新到 TeamCity 2020.1 后，您会收到 “Error creating bean with name "jetbrains.buildServer.dotnet.DotnetRunnerRunType"”。 为了解决这个问题，请从您的服务器上卸载过时的插件。
请注意，所有现有的 .NET CLI Support 构建步骤会在更新到 TeamCity 2019.2.3 或更高版本时自动切换到新的 .NET 运行器。 要获取更多信息，请参阅我们的 升级说明。
在使用早期的 Visual Studio 2017 构建时，无法创建 logger 的实例
在罕见的情况下，如果您的构建代理上安装了 Visual Studio 2017 的早期版本，那么在运行 .NET 构建步骤时，您可能会遇到 "无法创建记录器的实例" 的错误。 这可能是由于记录器与正在使用的框架版本不兼容所导致的。
为了解决这个问题，您可以将 Visual Studio 2017 升级到最新的版本，或者选择安装任何更高版本的 .NET Framework。
解析 .rsp 文件（错误 MSB1006：属性无效）
由于 Microsoft 在核心 System.CommandLine 库中引入的 破坏性更改，带有逗号和（或）分号的属性值的 .rsp 文件解析错误。 为确保此问题不会发生，请将 系统属性 的值用引号括起来。 如果这个解决方案不适用于您的项目，请添加 teamcity.internal.dotnet.msbuild.parameters.escape 配置参数，并将其值设定为 "true"。 启用此设置后，TeamCity 将自动将用户定义的属性值用引号包围。
NuGet 已知问题
预发布包在 TeamCity NuGet 源中不可见
问题：预发布的包在 TeamCity NuGet 馈送中看不到。
原因：如果包版本违反了 所需的格式，则 NuGet 客户端 3 版之前无法列出预发布包。
解决方案：删除版本违反所需格式的构建工件。
在 TeamCity NuGet 源中，包的索引速度较慢
问题：在移动或升级 TeamCity 服务器主机机器后，构建元数据可能会被重置。
原因：TeamCity NuGet 源依赖于构建元数据，而且根据包的数量和 TeamCity 服务器的空闲时间，包的重新索引可能需要大量时间。
解决方案：为了加速构建元数据的重新索引，指定以下内部属性：
要查看元数据索引进度，请在 teamcity-server.log 文件中寻找以下类似的行：
在重新索引完成后，删除这些内部属性。
NuGet 不会拉取最新的包版本
问题：NuGet 在从源中拉取这些包时，有时会跳过这些包的最新版本。
原因：NuGet 缓存了服务器响应，因此拉取操作无法检测到源中最新的更改。
解决方案：要直接向服务器发送新请求，而不是向缓存，您可在请求中使用 --no-cache 参数。
在 NuGet 源中找不到包
问题：尽管磁盘和用户界面中存在工件，但并非所有的包都能在 NuGet 源中找到，且 teamcity-nuget.log 并未显示正在进行包的索引。
原因：可能的原因之一可能是 TeamCity 是从备份中恢复的，或者被迁移到了新的服务器。
解决方案：清除 buildsMetadata 缓存，并等待服务器上的包重新索引完成。 请注意，对于具有长时间构建历史的大型服务器，这可能需要很多时间。
无法在 PowerShell 中使用多行参数
早期版本的 PowerShell 运行器不支持传递多行参数。 自2020.1.4版本起，您可以通过设置 teamcity.powershell.arguments.multiline=true 配置参数 来启用此支持。
加载 VCS 更改时出错
加载 VCS 更改时出错可能与在 MySQL 中启用的基于光标的流式处理有关。这种情况可能在 TeamCity 服务器启动时发生。 为了防止此错误，尝试在 database.properties 中将 connectionProperties.useCursorFetch 属性设置为 false ，然后重新启动服务器。
更多详细信息，请查看 此问题。
Pull Requests 构建功能的已知问题
在某些情况下，TeamCity 可能会在 JetBrains Space 中的旧开放合并请求和 Bitbucket Cloud 中的拉取请求上启动构建。 此问题可以通过以下步骤复现：
创建一个新的 VCS 根，以连接到一个有开放合并请求的仓库。 保留默认分支规格说明。
使用此 VCS 根目录和 VCS 触发器创建一个构建配置。
从 VCS 根中删除分支规格。
将 Pull Requests 构建功能添加到构建配置中。
禁用 Pull Requests 功能，然后再次启用它。
请查看 相关问题 以获取更多细节。
Pull Requests 构建功能可能会向 JetBrains Space 的合并请求时间线上传一个错误的构建步骤编号。 请查看 相关问题。
与 Git 仓库所有权检查相关的问题
由于 Git 2.35.2 中引入了 更严格的存储库所有权检查，更新 TeamCity 服务器的 Git 到此版本或更高版本可能会导致故障（例如，出现 "fatal: could not read from remote repository" 消息）。 尝试以下解决方案作为暂时的办法：
如果您的 TeamCity 服务器运行在 Linux 上，请确保 <TeamCity 数据目录>/system/caches/git 目录的卷是在 TeamCity 用于访问此目录的同一用户下挂载的。
如果您在通过 Windows Docker 镜像安装或更新的 TeamCity 服务器 上遇到相关问题，请禁用 native Git 以强制 TeamCity 服务器使用 JGit 代替。
原生 Git checkout 已知问题
这些问题涉及在 TeamCity 服务器上使用原生的 Git 来检出资源，该应用自 2022.04 版本起就生效了。
SSH DSA 密钥无法与本地 Git 一起使用
将服务器切换到原生 Git 会导致构建无法通过 SSH DSA 键授权仓库。 参见相关问题 TW-74580。
为了解决这个问题，请将 teamcity.git.sshCommandOptions 内部属性 设置为 -o "PubkeyAcceptedKeyTypes=+ssh-dss""。
通过 OpenSSH 使用的原生 Git 可能会失败
如果服务器/代理安装路径包含空格，Windows 上通过 OpenSSH 使用原生 Git 可能会失败。 请查看 相关问题。
ssh 代理的 nonProxyHosts 选项不可用
TeamCity 在通过原生 Git 连接时使用 ssh 代理。 查看 相关问题
原生 Git 不支持自定义 ssl 证书
服务器上原生 Git 不支持自定义 ssl 证书。 查看 相关问题
此问题已在 TeamCity 2022.10.1 中得到修复。
将工件发布至第三方 S3 兼容存储可能会失败
TeamCity 2022.04 的更改 与 Amazon S3 工件存储有关的 ACL 设置， 可能导致发布工件到第三方 S3 兼容存储，如 Backblaze ，失败。
若在更新至 TeamCity 2022.04 后遇到此问题，请从 相关问题 中下载插件版本，并添加所需的 acl 值的 storage.s3.acl 配置参数。 所有在 这里 列出的值都得到支持。
工件解压问题
常规的 ZIP 格式支持的存档大小可达到 2^32 字节（4 GB）。 由于构建可能会生成超过此值的工件，TeamCity 使用支持高达2^64字节（16 exabytes）的大型档案的 ZIP64 格式来压缩工件。
如果您用来解压 TeamCity 构建工件的工具不支持 ZIP64（例如，您可能会看到头错误警告），请向项目（要么是 <Root project>，要么是生成不受支持的档案的特定项目）添加以下配置参数：