已知问题
这个页面包含了一份关于 TeamCity 已知问题的解决方案列表。
要查看针对 TeamCity 特定版本的问题,请前往 升级说明 的相应部分。
在 JDK 8u242+ 下运行的 TeamCity 版本最高可达 2019.2.1,可以报告 java.lang.NoClassDefFoundError:无法初始化类 XXX
错误,例如,在 Git 操作或 Windows 域认证操作上。
在 TeamCity 2019.2.2 发布之前,建议您使用 Java 8u232 版本进行 TeamCity 服务器。
当 TeamCity 构建代理安装为 Windows 服务时,在构建过程中可能出现各种"权限被拒绝"或"访问被拒绝"的错误,具体详见以下内容。
作为 Windows 服务,TeamCity 代理和构建过程无法访问网络共享和映射驱动器。
为了克服这些限制,运行 TeamCity 代理 通过控制台。
这些问题包括无头运行测试的错误,TeamCity 代理与 Windows 桌面交互的问题等等。
tip
请注意,通过 mstsc 访问远程计算机在 Windows 有一个限制:在 RDP 断开连接时,远程机器的桌面将被锁定,这将导致运行测试时出现问题。 VNC 协议允许您远程控制另一台机器,而无需将其锁定。要运行 GUI 测试并能够使用 RDP,请参阅下面的 解决方法。
为了解决/避免以下问题:
运行 TeamCity 代理 通过控制台。
配置构建代理机器不启动锁定桌面的屏保。
将 TeamCity 代理配置为自动启动(例如,在 Windows 启动时配置自动用户登录,然后在用户登录时(通过
agent.bat start
)配置 TeamCity 代理启动)。
对于图形测试,构建代理不能作为服务启动,建议在用户自动登录后的1分钟后配置构建代理启动,例如,使用任务调度程序中的 bin\agent.bat start
命令并在那里配置延迟。
RDP 使用其自身的视频驱动程序来覆盖会话中机器视频卡的驱动程序。 将会话重定向到控制台将卸载 Windows 图形驱动程序。 您可以通过在进行测试之前,向您的构建配置中添加以下步骤来实现这一点(下面的示例是用于 PowerShell 的,但也可以使用其他语言(如 DOS,Python)):
$sessionInfo=((quser $env:USERNAME | select -Skip 1) -split '\s+')
if ($sessionInfo[1] -like "rdp-tcp*") { tscon $sessionInfo[2] /dest:console }
在这里 quser [当前用户名]
列出了用户对该机器的所有连接,无论是控制台还是图形界面。
被列为 rdp-tcp#*
的是远程桌面连接,可以使用 tscon [连接 id] /dest:console
重定向到控制台。
note
一个无人监管的计算机,其桌面程序始终在用户会话中处于登录状态,可能被视为网络安全威胁,因为追踪到它的访问可能会很困难。 因此,建议在与敏感的公司网络资源隔离的虚拟机上运行自动化 GUI 和浏览器测试,例如在未包含在 Windows 域中的机器上运行。
当 TeamCity 代理作为 Windows 服务启动,并且 .NET 应用程序的自动化测试使用 Selenium WebDriver 时,由于浏览器驱动器的限制,测试可能会失败。 作为一种解决方案,考虑手动启动代理 manually。
为了处理这个问题,可以考虑使用服务设置的 自动(延迟启动) 选项,或者配置 服务依赖性。
要了解更多的调查步骤,请查看 常见问题 页面。
如果您的 TeamCity 服务器运行在 SUSE® Linux 企业版(或者使用 systemd Daemon)上,java.lang.OutOfMemoryError: unable to create new native thread error可能是由于cgroup 进程数量控制器的特性导致的,该特性默认限制了一个 cgroup 中的进程数量和线程数量为 512。
在 TeamCity 服务器上增加限制(例如,增至 4096)应该可以解决此问题。
也可以参阅这个 外部发布。
一些用户遇到了与网络界面相关的问题(其他计算机无法复现该问题),这与缓存版本的内容有关。 如果您遇到了此类问题,请确保您的浏览器未使用内容的缓存版本,方法是清除浏览器缓存。
如果您在测试中使用 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>
使用的 Java Service Wrapper 版本并未完全支持 Windows 64 ,这导致用户注销时,代理启动器进程被终止。 代理本身将一直运行,直到下一次重启(服务器升级或代理属性更改)。
这是 Maven 当前版本中的一个已知错误。 请考虑使用任何较新的版本。
如果无法做到,您可以通过替换 mvn.bat
中第 148 行的片段来自行修补 mvn.bat
。
:error
set ERROR_CODE=1
与以下内容一致:
:error
if "%OS%"=="Windows_NT" @endlocal
set ERROR_CODE=1
最常见的冲突软件指示符是像“拒绝访问”,“权限被拒绝”或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)。
在构建服务器上添加系统属性 -Dsvnkit.http.sslProtocols=SSLv3,TLS
(参见 配置 TeamCity 服务器启动属性)。
如果您在 agent 上使用 checkout,则还需在构建 agent 上添加此属性 在构建 agent 上。
如果在执行与 SVN 相关的代码时(例如在 org.tmatesoft.svn 包下),JVM 崩溃,您可以尝试使用以下选项之一来禁用它:
将
-Dsvnkit.useJNA=false
JVM 选项传递给崩溃的进程(服务器或代理)通过传递
-Dsvnkit.http.methods=Basic,Digest,NTLM
JVM 选项,降低 NTLM 支持的优先级。
无论如何,我们推荐将使用的 JVM 升级到最新可用版本。
由于 NUnit 2.4.6 中的一个问题,它的性能可能会比 NUnit 2.4.1 慢。 如需更多信息,请参考我们问题跟踪器中对应的问题:TW-4709
在 TeamCity 服务器上使用 StarTeam SDK 9.0 替代 StarTeam SDK 9.3 可以在 TeamCity 和 StarTeam 服务器之间的连接速度较慢时,显著提高 VCS 的性能。
如果您在 Windows 上运行 Perforce 2009.2 ,您可能会经历显著的速度减慢。 这是一个在 Windows 上运行的 P4 服务器出现的问题。 参考 Perforce 文档中相应的 部分。
请确保您使用针对您的平台的最新 Java 8 安装更新(例如,由 Amazon Corretto 提供的 OpenJDK 8)。
在您升级到 IntelliJ IDEA X (或其他 IntelliJ X 平台产品)之前,确保您没有活动的预测试提交,否则升级后将无法提交。 如果您使用基于目录的 IDEA 项目(项目文件存储在 .idea
目录下),这只是相关的。
如果同一主机名下还有其他可用的网络应用,可能会出现会话cookie冲突。 这通常表现为随机用户登出或丢失会话级数据。 (例如,TW-12654)。 为了解决这个问题,您可以在访问应用程序时使用不同的主机名。
只有一个 TeamCity 服务器可以与一个数据库一起工作,这在 TeamCity 服务器启动时进行检查。
"在以下任何一种情况下,都会报告" 数据库正在使用中
"在启动时出现错误:
尝试启动多个连接到同一数据库的 TeamCity 服务器
检测到第二个 TeamCity 实例
内部的 HSQL 数据库正在被另一款应用程序使用
错误很可能是由于另一个正在运行的 TeamCity 安装连接到了同一数据库所导致的。 请检查数据库属性是否正确,确保没有其他的 TeamCity 服务器使用相同的数据库。
如果您在从 TeamCity 下载构件时遇到下载速度慢的问题,尝试在服务器机器上检查速度,从 localhost 下载。 如果 localhost 的速度可以,那么问题可能出在网络配置或者操作系统 / 硬件设置上,当它们与 TeamCity(Tomcat)设置结合时。
确保 <TeamCity 安装目录>\conf\server.xml 文件对应于包含在 TeamCity 发行版中的文件(可以在 .tar.gz 发行版中进行检查)。 如果您有以下的 "Connector" 节点(端口号可能会有所不同):
<Connector port="8111" protocol="HTTP/1.1"
connectionTimeout="60000"
redirectPort="8543"
useBodyEncodingForURI="true"
/>
将其更改为:
<Connector port="8111" protocol="org.apache.coyote.http11.Http11NioProtocol"
connectionTimeout="60000"
redirectPort="8543"
useBodyEncodingForURI="true"
socket.txBufSize="64000"
socket.rxBufSize="64000"
tcpNoDelay="1"
/>
并重新启动 TeamCity 服务器。
如果这对下载速度没有帮助,为了调查此问题,您可能需要找到一位具备适当网络相关问题调查技能的管理员来研究这个案例。
此问题仅与涉及在构建服务器和代理服务器之间的 IIS 反向代理的配置相关。 有时,构建代理可能会陷入无限循环,试图将构建工件发布到服务器上。 构建日志如下所示:
[11:15:05]Publishing artifacts
[11:15:05][Publishing artifacts] Collecting files to publish: [toZip/** => artifact.zip]
[11:15:06][Publishing artifacts] Creating archive artifact.zip (9s)
[11:15:06][Creating archive artifact.zip] Creating C:\BuildAgent\temp\buildTmp\ZipPreprocessor2847146024236637664\artifact.zip
[11:15:15][Creating archive artifact.zip] Archive was created, file size 32142324 bytes
[11:15:15][Publishing artifacts] Sending toZip/**
[11:15:25][Publishing artifacts] Sending toZip/**
[11:15:39][Publishing artifacts] Sending toZip/**
[11:15:48][Publishing artifacts] Sending toZip/**
[11:16:01][Publishing artifacts] Sending toZip/**
[11:16:16][Publishing artifacts] Sending toZip/**
与此同时, teamcity-agent.log
充满了 IIS 产生的 404 响应:
[2012-08-01 12:04:55,514] WARN - jetbrains.buildServer.AGENT - <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"/>
<title>404 - File or directory not found.</title>
<style type="text/css">
<!--
body{margin:0;font-size:.7em;font-family:Verdana, Arial, Helvetica, sans-serif;background:#EEEEEE;}
fieldset{padding:0 15px 10px 15px;}
这种情况最常见的原因是 maxAllowedContentLength
设置(在 IIS 中)要么
设置为过小的值,或者
留空未配置,因此默认为30000000字节(<30 Mb)
因此,任何大于 maxAllowedContentLength
的工件都会被 IIS 丢弃。请检查设置值,并尝试重新运行您的构建。
如果您的 TeamCity 服务器启用了 Artifacts Domain Isolation,尝试访问构建工件可能会导致 401 未授权错误。 这个问题很可能是由于您的 IIS 网络服务器的默认行为所引起的:它将目标从构件的域重新写回到主服务器域的响应头。 要禁用此行为,请转到 IIS 界面中的 应用程序请求路由 | 服务器代理设置 ,并禁用 "在响应标头中反向重写主机" 选项。
在加载 TeamCity 页面时,您可能会注意到一些内容缺失。 通常,已完成构建的构建配置不会显示其构建历史,看起来是空的。 与此同时,网络浏览器记录了多个 404 (未找到)错误。
如果这种情况发生在运行在 IIS 服务器上的 TeamCity 实例上,请检查 IIS 的 maxQueryStringLength
和 / 或 maxQueryString
的值。 这些设置限制了查询字符串的最大长度。 如果这些限制太低,TeamCity 发送到 <服务器网址>/app/rest/...
端点的一些 REST 请求可能会失败。
要解决此问题,您需要在 IIS 服务器的 web.config
文件中提高这些限制。 精确的值应取决于您当前的配置和您的项目/配置 ID 的长度。 一般来说,建议您将此限制设置为4000个字符,如果问题仍然存在,则逐渐提高它。
另见:请求限制 | httpRuntime 元素
当从 1.6 切换到 1.7 的 JVM 并连接一些配置不正确的 HTTPS 服务器时,可能会出现这个问题。 问题和解决方法在 此问题 中进行了描述。
当在已经安装了不同版本 Java 的代理上通过 Windows 代理安装程序 安装一个 TeamCity 代理时,"配置构建代理属性" 安装窗口可能会显示扭曲。
此问题已在 TeamCity 2019.1.5 中得到修复。
为了解决此问题,而无需升级至 2019.1.5 ,请在同一目录中安装新代理程序前,卸载已安装的先前版本代理程序。
若要卸载代理程序,请在 代理主目录 中调用 Uninstall.exe
,清除所有 "移除..." 的复选框以保留代理日志和配置,然后点击 卸载。 成功卸载后,您可以通过代理安装程序继续安装新的代理版本。
自动的 TeamCity 更新可能无法将新版本号写入相关的 Windows 注册表键。 这会使标准的 Windows 添加或删除程序应用程序显示最初的 TeamCity 安装版本,该版本在更新后从不改变。
要手动更新注册表键并设置正确的版本,请按照 TeamCity 管理员 | 更新 页面上的说明运行与您的 TeamCity 安装包一同提供的 PowerShell 脚本:
runas /user: Administrator "powershell -File C:\TeamCity\bin\update-registry-version.ps1"
与 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 10 上,Docker 服务器依赖于 Hyper-V 服务,其启动可能需要大量的时间。 为了解决这个问题,请将 TCBuildAgent Windows 服务配置为依赖于 Docker for Windows 服务, com.docker.service
默认。
容器包装器 在启动 Windows-based 容器时可以在 Windows 上运行。
如果在 Windows 机器上启动了 Linux 容器,TeamCity 将显示错误消息 "在 Windows 下启动 Linux Docker 容器是不支持的。 为了避免这个问题,添加的 teamcity.agent.jvm.os.name
不包含 Windows 代理要求。
如果您需要支持在 Windows 平台下运行 Linux 容器的使用情况,容器包装器 请为 TW-51820 中的相关评论投票。
在使用 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
目录指定一个专用的卷映射。 我们也建议确保为此过程分配了足够的资源。
docker run --memory="6g" --cpus=4 -e TEAMCITY_SERVER_MEM_OPTS="-Xmx3g -XX:MaxPermSize=270m -XX:ReservedCodeCacheSize=640m" --name teamcity-server-instance
-v <path-to-data-directory>:C:/ProgramData/JetBrains/TeamCity
-v <path-to-logs-directory>:C:/TeamCity/logs
-v <path-to-temp-directory>:C:/TeamCity/temp
-p <port-on-host>:8111 jetbrains/teamcity-server
或者,您可以为 %PROGRAMDATA%\docker\volumes
目录授予 "Authenticated Users" 组 "Full control" 权限。
如果您尝试在带有 Nano Server OS 的代理上运行 dotCover,构建将以退出错误“Process exited with code -1073741515”失败。 与其使用 Nano Server,不妨考虑使用 Server Core,它是 Windows Server 的另一种最小化安装选项。
dotCover 不支持收集 dotnet msbuild /t:vstest
命令的覆盖率统计信息,请改为使用 dotnet test
。
在 dotCover 中,使用测试设置进行代码覆盖率配置已被弃用。 在 Microsoft 文档中阅读更多内容。
如果您使用 .testsettings
文件,TeamCity 将在日志中显示警告信息。 为了防止这个问题,我们建议您使用 .runsettings
文件代替。 如果因为某些原因,您必须继续使用 .testsettings
,请在 TeamCity 代理上安装 2019.1.x 或更早版本的 dotCover,如此处所述。
如果您使用自定义输出目录为 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 中,请转到 偏好设置 | 隐私,并禁用 "阻止跨站点跟踪" 选项。
note
禁用此设置将降低您浏览器的整体安全性。 仅在必要时使用此解决方法。 我们强烈建议您等待下一个版本的 TeamCity 解决此问题。
这个问题将在 TeamCity 2020.1.5 更新中得到解决。 请查看 相关问题 以获取更多细节。
重新设计的 .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 的早期版本,那么在运行 .NET 构建步骤时,您可能会遇到 "无法创建记录器的实例" 的错误。 这可能是由于记录器与正在使用的框架版本不兼容所导致的。
为了解决这个问题,您可以将 Visual Studio 2017 升级到最新的版本,或者选择安装任何更高版本的 .NET Framework。
由于 Microsoft 在核心 System.CommandLine
库中引入的 破坏性更改,带有逗号和(或)分号的属性值的 .rsp 文件解析错误。 为确保此问题不会发生,请将 系统属性 的值用引号括起来。 如果这个解决方案不适用于您的项目,请添加 teamcity.internal.dotnet.msbuild.parameters.escape
配置参数,并将其值设定为 "true"。 启用此设置后,TeamCity 将自动将用户定义的属性值用引号包围。
问题:预发布的包在 TeamCity NuGet 馈送中看不到。
原因:如果包版本违反了 所需的格式,则 NuGet 客户端 3 版之前无法列出预发布包。
解决方案:删除版本违反所需格式的构建工件。
问题:在移动或升级 TeamCity 服务器主机机器后,构建元数据可能会被重置。
原因:TeamCity NuGet 源依赖于构建元数据,而且根据包的数量和 TeamCity 服务器的空闲时间,包的重新索引可能需要大量时间。
解决方案:为了加速构建元数据的重新索引,指定以下内部属性:
teamcity.buildIndexer.indexPackSize=1000
teamcity.buildIndexer.packSleepDurationMs=10
要查看元数据索引进度,请在 teamcity-server.log 文件中寻找以下类似的行:
INFO - .index.BuildIndexer (metadata) - Enqueued next 100 builds for indexing, builds left: 7064, last build id: 8142
在重新索引完成后,删除这些内部属性。
问题:NuGet 在从源中拉取这些包时,有时会跳过这些包的最新版本。
原因:NuGet 缓存了服务器响应,因此拉取操作无法检测到源中最新的更改。
解决方案:要直接向服务器发送新请求,而不是向缓存,您可在请求中使用 --no-cache
参数。
问题:尽管磁盘和用户界面中存在工件,但并非所有的包都能在 NuGet 源中找到,且 teamcity-nuget.log 并未显示正在进行包的索引。
原因:可能的原因之一可能是 TeamCity 是从备份中恢复的,或者被迁移到了新的服务器。
解决方案:清除 buildsMetadata 缓存,并等待服务器上的包重新索引完成。 请注意,对于具有长时间构建历史的大型服务器,这可能需要很多时间。
早期版本的 PowerShell 运行器不支持传递多行参数。 自2020.1.4版本起,您可以通过设置 teamcity.powershell.arguments.multiline=true
配置参数 来启用此支持。
加载 VCS 更改时出错可能与在 MySQL 中启用的基于光标的流式处理有关。这种情况可能在 TeamCity 服务器启动时发生。 为了防止此错误,尝试在 database.properties
中将 connectionProperties.useCursorFetch
属性设置为 false
,然后重新启动服务器。
更多详细信息,请查看 此问题。
在某些情况下,TeamCity 可能会在 JetBrains Space 中的旧开放合并请求和 Bitbucket Cloud 中的拉取请求上启动构建。 此问题可以通过以下步骤复现:
创建一个新的 VCS 根,以连接到一个有开放合并请求的仓库。 保留默认分支规格说明。
使用此 VCS 根目录和 VCS 触发器创建一个构建配置。
从 VCS 根中删除分支规格。
将 Pull Requests 构建功能添加到构建配置中。
禁用 Pull Requests 功能,然后再次启用它。
请查看 相关问题 以获取更多细节。
Pull Requests 构建功能可能会向 JetBrains Space 的合并请求时间线上传一个错误的构建步骤编号。 请查看 相关问题。
由于 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 代替。
这些问题涉及在 TeamCity 服务器上使用原生的 Git 来检出资源,该应用自 2022.04 版本起就生效了。
将服务器切换到原生 Git 会导致构建无法通过 SSH DSA 键授权仓库。 参见相关问题 TW-74580。
为了解决这个问题,请将 teamcity.git.sshCommandOptions
内部属性 设置为 -o "PubkeyAcceptedKeyTypes=+ssh-dss""
。
如果服务器/代理安装路径包含空格,Windows 上通过 OpenSSH 使用原生 Git 可能会失败。 请查看 相关问题。
TeamCity 在通过原生 Git 连接时使用 ssh 代理。 查看 相关问题
服务器上原生 Git 不支持自定义 ssl 证书。 查看 相关问题
此问题已在 TeamCity 2022.10.1 中得到修复。
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>,要么是生成不受支持的档案的特定项目)添加以下配置参数:
teamcity.internal.artifacts.useZip64=Never
teamcity.internal.artifacts.useByteChannelForZip=false
感谢您的反馈!