TeamCity 2020.2 中的新功能
新的标题
TeamCity 2020.2 在经典和实验性用户界面中都带有更现代的标题。
开箱即用的 Python 支持
TeamCity 2020.2 新增了一个内置的 Python 运行器。 它会自动在构建代理上检测 Python，并允许在所有支持的平台上运行 Python 脚本。
与现已过时的 Python Runner 插件相比，新的运行器与 TeamCity 紧密集成，并引入了额外的可能性，例如：
自动测试报告（通过 unittest 和 pytest）和检查（通过 flake8 和 pylint）
使用虚拟环境
在 Docker 容器内启动构建步骤
如果您过去使用旧插件来运行您的 Python 项目，我们强烈推荐将相应的构建步骤切换至捆绑的 runner。 由于新的运行器提供了额外的设置，这些步骤必须手动重新配置。
阅读 如何配置新的运行器。
无代理构建步骤
自此版本以后，构建的最后步骤可以在没有构建代理的情况下，在外部软件中完成。
通常，一个正在运行的构建会占用构建代理，直到其所有步骤完成。 在某些情况下，构建需要等待由构建代理外部的某个外部系统执行的进程。 例如，当最后一步是由第三方软件负责部署时，代理只会在这一步完成之前什么都不做。
现在，构建可以从其当前代理中分离出来。 此代理变为其他构建可用，而构建将继续在 "无代理" 模式下运行。
要分离代理，构建应发送 ##teamcity[buildDetachedFromAgent] 服务消息。
有专用的 REST API 端点可用于报告无代理构建的进度，并在外部流程结束后结束它。 您可以在 文档 中阅读更多相关内容。
无代理构建同时运行的数量是有限制的。 它等于您的安装中授权代理的最大数量。 这样，如果您有 10 个代理许可证，您可以并行运行最多 10 个代理 加最多 10 个无代理构建。
如果超出限制，构建无法从其代理中脱离，直到一些正在运行的无代理构建完成。
使用 GitHub.com ， GitHub Enterprise ， GitLab.com ， GitLab CE/EE ， Bitbucket Cloud 进行身份验证
现在，用户可用他们的外部帐户在 TeamCity 中进行身份验证：
这种集成需要在 VCS 托管提供商的侧面创建一个专用应用程序，并在 TeamCity 中创建一个 连接。 您可以在此处找到关于如何配置连接的详细说明 这里。
为了启用与每个列出的提供商的身份验证，系统管理员需要激活相应的 认证模块。 如果您的服务器启用了这些模块中的任何一个，用户将在登录表单上方看到其图标：
要以外部用户的身份登录，您需要点击这个图标，然后，在重定向后，批准您的外部帐户中的 TeamCity 应用程序。 如果成功，您将重新登录至 TeamCity。
如果您的外部帐户的电子邮件在 TeamCity 中注册过，您将以该用户身份进行身份验证。 否则，TeamCity 将创建一个新的用户配置文件（除非手动禁用此选项）。
为了让 TeamCity 自动识别，用户还可以将其配置文件连接到 我的设置与工具 中的外部账户。
管理员可以将 TeamCity 用户与外部帐户进行匹配，并限制可以访问服务器的提供商组织 / 组织 / 工作空间的成员。
学习 如何启用和管理身份验证模块。
支持 Bitbucket Cloud 的拉取请求
TeamCity 已经支持在 GitHub、GitLab、Azure DevOps 和 Bitbucket Server 中监控拉取请求。 现在 — 在 Bitbucket Cloud 中。
当您向 Bitbucket Cloud 仓库发送拉取请求时，TeamCity 会检测到它，运行一个新的构建，然后显示拉取请求的结果。 为了使此功能正常工作，您需要配置 Pull Requests 构建功能和 VCS 触发器。
请注意，该功能在 Bitbucket Cloud 中的操作方式与其他 VCS 略有不同。 由于 Bitbucket Cloud 不会为每个拉取请求创建一个专用分支，因此 TeamCity 仅在拉取请求的源分支上运行构建，并且只监控源代码库（不支持 forks）。
查看 更多详细信息。
JetBrains Space 在 Commit Status Publisher 中的支持
构建功能 Commit Status Publisher 可以与 JetBrains Space 进行集成。 凭借此功能，TeamCity 构建可以自动实时将其状态发布到 JetBrains Space 项目中。
阅读 如何配置此集成。
实验性用户界面更新
我们的 experimental UI 还在开发过程中：我们会在开发的早期阶段就引入变化，这样您就可以从新功能中获益了。 在每个版本中，我们都会对已有的实验性页面进行打磨，并在新的用户界面中复制所有重要的经典功能。 我们的路线图很大程度上取决于用户的反馈。
在 2020.2 版本中，我们添加了 测试历史 和 构建队列 页面，实现了构建日志的全文搜索，并改进了构建结果的 依赖 选项卡。
如果缺少任何熟悉的功能，您可以通过
实验性测试历史页面
在此版本中，备受需求的 测试历史 页面焕然一新。 现在，您可以查看详细的测试统计信息，而无需切换到经典模式。
构建日志中的全文搜索
您现在可以搜索构建日志，无论其在用户界面中已加载了多少。
更新的依赖关系显示
我们收到了许多请求，在实验性用户界面的构建链时间线上显示排队的构建。 在此版本中，我们已更新构建链显示，使其更具信息性：
依赖关系 | 时间线 视图显示了当前构建的所有依赖项，包括排队的依赖项。
依赖关系 | 链 视图显示了完整的构建链。 您可以查看所有依赖于当前构建的构建，并将当前构建推广给它们，就像在经典 UI 中一样。 如果构建是 composite ，您也可以直接从此视图中对其进行分组。
在实验性用户界面中插件支持
现在，您可以使用现代网络技术和不同的框架为实验性用户界面编写插件。 请参阅 这篇博客文章 以获取更多详情。
实验性构建队列页面
我们正在积极开展构建队列新表示法的工作。 从 TeamCity 2020.2.2 开始，新队列默认显示。 在早期版本中，您可以通过点击屏幕右上角的试管图标切换到它。
新的侧边栏在 项目 和 支持人员 页面上对我们的用户非常有帮助。 现在，它也适用于 队列页面 ，这对于拥有多个代理池的大型安装非常有帮助。
您也可以点击队列中的任何构建以查看其详细信息：
可自定义的清理计划
TeamCity 服务器清理功能在支持 cron-like expressions 的帮助下变得更加灵活。 您可以自定义调度，以便清理工作以任何必要的频率开始：例如，每周末或每天两次。
请记住，过于频繁的清理可能会过度占用 CPU ，而太少的清理则需要更多的时间，并可能导致垃圾堆积。 我们建议保持清理计划的均衡。 在大多数情况下，每日进行一次清理就足够了，但是负载较高的安装可能需要更频繁地运行清理。
限时访问令牌
TeamCity 可以生成有时间限制的 access tokens。 您可以在脚本或其他 REST API 请求中使用这些令牌，以授予 TeamCity 服务器临时访问权限。 在令牌的时间限制过后，TeamCity 将自动撤销其访问权限。
要添加新令牌，请转到 我的设置与工具 | 访问令牌：
在次级节点上编辑项目设置
TeamCity 2020.2 为次要节点新增了一个 新责任。 如果授予一个节点，它将允许UI操作：运行，停止，标记，评论构建等多种操作。 用户现在也可以在二级节点上编辑项目和构建配置（有一些限制，如编辑云配置文件）。
禁用此责任将使二级节点切换到只读模式。
另请参阅 升级说明。
监控外部存储中的磁盘使用情况
越来越多的用户喜欢将构建工件存储在云中 - 例如，在 Amazon S3 中。 然而，以前无法看到存储在那里的数据量。
磁盘使用情况报告现在支持外部 工件存储。 它显示了在每个已配置的存储中或在所有的存储中一次存储的数据量。 此外，如果您为本地存储配置了多个构建工件目录，您现在也可以分别查看每个目录的报告。
在 管理 | 磁盘使用情况 页面，您可以在检测到的存储之间切换并查看详细报告：
使用自定义设置标识构建
现在更容易区分“自定义”构建和常规构建了。 如果构建是使用自定义参数或者构件依赖进行的，或者并非在最新的提交上进行，TeamCity 将会在视觉上标记这样的构建。 在构建列表中，它将在此构建对应的图标和提示：
并且在构建结果中：
点击提示中的链接以打开构建结果的相关标签页。
在成功重试后静音失败的测试
某些构建可以在测试失败时进行重试。 这对于 flaky tests 最为方便。 当将此类测试应用于同一源修订版本时，它们可能会交替失败和成功，您可能希望排除它们对构建状态的影响。
现在，如果在您的构建中启用了 test retry ，那么如果在同一次构建运行中最终成功，TeamCity 将静音失败的测试。 这个测试不会影响构建状态，只要没有其他问题，构建将会成功完成。
请在 文档 中查看更多详情。
其他改进
拉取请求的源分支过滤器
TeamCity 不仅可以按目标分支，还可以按源分支过滤拉取请求。 它允许您轻松地从监控范围中排除某些草稿分支。
请注意，此过滤器不适用于 Bitbucket Cloud，因为 TeamCity 直接在源分支上监控拉取请求。在构建步骤之间传递 NuGet 包
如果您需要发布 NuGet 包并在一个构建中使用其内容，您需要确保它们按时发布并被索引，而不是在构建完成时。 以前，需要使用 NuGet Publish 步骤。 从这个版本开始，构建步骤可以发送##teamcity[publishNuGetPackage]服务消息。 这确保了 NuGet 包在当前构建步骤结束时就已发布到所有配置的 NuGet 源中，并且在后续构建步骤中可用。更快的代理 Docker 容器冷启动
从此版本开始，TeamCity 代理 Docker 镜像基于完整的代理分发版。 完整的代理包含所有捆绑的插件。 这大大加快了代理冷启动的速度，因为完整的代理无需与服务器同步所有插件。 当启动时，它只会下载安装在您的服务器上的外部插件或工具（如有）。
请注意，只有当 Docker 镜像匹配服务器版本时，此改进才有效。更简单的 Perforce SSH 根配置
如果您的项目的 VCS 根通过 SSH 连接到 Perforce，TeamCity 将自动与其建立受信任的连接。 现在，每次您测试 Perforce 连接或构建代理从 Perforce 检出时，都会发送p4 trust命令。限制每次构建发布的制品数量
这有助于防止多个构建并行发布大量工件时的内存消耗和性能问题。
在所有新安装中，此数值设置为 1000。 在升级现有的 TeamCity 安装时，此数字将保持无限制。 您可以在 管理 | 服务器管理 | 全局设置 中限制该值。 请注意，此限制不考虑隐藏的工件。复合构建的执行超时时间
当一个 复合构建 包含一个无法启动的构建（例如，没有兼容的代理）时，该复合构建可能会无限运行，直到手动终止。 现在，您可以为此类构建设置执行超时，如果长时间无法启动，它将自动失败。支持 S3 路径前缀
现在，您可以在配置 Amazon S3 工件存储时设置路径前缀。 这允许所有 TeamCity 项目使用相同的 S3 存储桶，并配置基于前缀的权限。更新的拉取请求图标
构建结果中表示拉取请求的图标现在更大，并根据拉取请求状态更改颜色，帮助您更快地识别其状态。关于不安全的 Tomcat 连接配置的健康报告
如果服务器安装在提供 HTTPS 访问的反向代理后，TeamCity 现在会检查 Tomcat 连接中是否存在secure="true"和scheme="https"属性。 如果这些属性缺失，TeamCity 将会显示相应的健康报告。没有默认的 Gradle 构建文件值
以前， 构建文件 字段在 Gradle 运行器中默认设置为build.gradle。 我们已经删除了此默认值，因为有些用户依赖于构建文件的自定义名称，并更愿意让 Gradle 决定选择哪个文件。
如果您使用build.gradle作为您的构建文件，那么所有内容都将像此次更新之前一样正常运行。REST API 更新:
.NET 构建运行程序现在支持早期版本的 Visual Studio 和 MSBuild。 当前支持的版本包括：Visual Studio 2010 或更高版本，MSBuild 4 / 12 或更高版本。
要查看所有捆绑工具的更新，请阅读我们的 升级说明。
版本 2020.2 提供了大约 30 项各种功能部分的性能修复（例如，在 Custom Run 对话框中）。
已解决的问题
升级说明
在升级之前，我们强烈建议阅读关于 version 2020.2 与 2020.1.x 之间重要变化的内容。
以前的版本
路线图
参阅 TeamCity 路线图 ，了解未来的更新。