TeamCity 2026.1.2 和 2025.11.6 已发布，这两个版本都属于错误修复更新。它们不是功能型大版本，但对日常 CI/CD 稳定性很关键：构建停止语义、Perforce 个人构建、AWS 凭证生命周期、S3 bucket 前缀处理等问题，都可能在流水线高频运行时放大成真实事故。
这类小版本为什么不能只看版本号
修复版本容易被团队低估，因为它们通常没有新的 UI、没有新的构建步骤类型，也不会改变你写 Kotlin DSL 的方式。但 CI 系统的风险不在“有没有新功能”，而在“旧流程是否仍然可信”。
这次 2026.1.2 修复了 10 多个问题，摘要里提到的几类尤其值得关注：
- 从服务器发出停止构建命令时，可能取消本应 always execute 的步骤。
- agent-side checkout 场景下，unshelving 某些 Perforce changelists 时，个人构建可能失败。
- AWS 凭证可能提前过期。
- AWS S3 bucket 前缀相关问题得到修复。
这些问题都有一个共同点：它们不一定每天出现，但一旦出现，排查路径很绕。比如 always execute 步骤通常承载清理、通知、归档日志、释放锁等动作；如果停止构建时它被跳过，失败表象可能不是“构建失败”，而是后续构建被脏工作区、悬挂资源或缺失制品拖垮。
停止构建与 always execute：别让清理步骤变成条件步骤
在 TeamCity 里，很多团队会把清理逻辑放进“始终执行”的步骤：无论测试失败、编译中断，还是人工停止构建，都希望它跑完。此次修复提到“从服务器发出停止构建命令可能会取消始终执行的步骤”，这类问题对长流水线尤其敏感。
可以这样实践：升级前后跑一个最小验证构建，确认人工停止构建后，清理步骤仍然执行。下面是一个可以改造成 TeamCity Command Line build step 的 shell 示例。
#!/usr/bin/env bash
set -euo pipefail
WORKDIR="${WORKDIR:-/tmp/teamcity-stop-test}"
mkdir -p "$WORKDIR"
cleanup() {
date -Is > "$WORKDIR/cleanup-ran.txt"
echo "cleanup executed: $WORKDIR/cleanup-ran.txt"
}
trap cleanup EXIT
echo "build started, pid=$$"
echo "Stop this build from TeamCity UI or server API within 60 seconds."
sleep 60
echo "build finished normally"
运行方式：
- 新建一个临时 build configuration。
- 添加一个 Command Line step，粘贴脚本。
- 将该 step 或后续清理 step 配置为 always execute。
- 在构建运行时从 TeamCity UI 停止它。
- 检查 agent 上是否生成
/tmp/teamcity-stop-test/cleanup-ran.txt，或检查 TeamCity build log 中的清理输出。
如果你的真实流水线里有 Docker 容器清理、临时环境销毁、数据库回滚、测试账号释放等动作，建议把这类验证加入升级验收清单。
Perforce、个人构建与 agent-side checkout 的交叉点
摘要中提到的另一个修复点是：在 agent-side checkout 时，unshelving 某些 Perforce changelists 会导致个人构建失败。
这说明问题发生在几个条件叠加时：
- 使用 Perforce。
- 使用 personal build。
- 使用 agent-side checkout。
- 构建过程中需要 unshelve changelist。
如果团队依赖 TeamCity 做代码评审前验证，这个修复会影响开发者体验。个人构建失败往往会被误判为代码问题，开发者会在本地重复构建、重新 shelve、换 changelist，最后才怀疑 CI 平台。
可以这样做一个升级前后的冒烟测试：准备一个包含 shelved changelist 的 Perforce 项目，触发一次 personal build，并记录以下信息。
# 在 TeamCity agent 或调试机上记录 Perforce 环境，便于失败时对比
p4 info
p4 changes -s shelved -m 5
# 如果需要验证某个 changelist，请替换 CL_NUMBER
CL_NUMBER=123456
p4 describe -S "$CL_NUMBER"
注意：这不是 TeamCity 官方升级脚本，只是一个可复制的诊断片段。真正的验证应该放在与你们生产 VCS root、checkout mode、agent pool 一致的 TeamCity 配置中。
AWS 凭证与 S3 前缀：CI 里的“偶发失败”常常是时间问题
本次摘要还提到 AWS 凭证提前过期，以及 AWS S3 bucket 前缀相关修复。这类问题对构建制品上传、依赖缓存、测试报告归档、部署包分发都有影响。
升级前可以先收集当前 TeamCity 服务器版本、项目使用的 S3 相关配置位置，以及最近是否出现过类似错误：
#!/usr/bin/env bash
set -euo pipefail
: "${TEAMCITY_URL:?Set TEAMCITY_URL, for example https://teamcity.example.com}"
: "${TEAMCITY_TOKEN:?Set TEAMCITY_TOKEN to a TeamCity access token}"
curl -fsS \
-H "Authorization: Bearer ${TEAMCITY_TOKEN}" \
-H "Accept: application/json" \
"${TEAMCITY_URL%/}/app/rest/server" \
| python3 -m json.tool
运行前需要设置：
export TEAMCITY_URL="https://teamcity.example.com"
export TEAMCITY_TOKEN="replace-with-a-read-only-token"
./check-teamcity-server.sh
如果你们用 S3 做 artifact storage 或构建缓存，升级验收可以包含一个小文件上传、下载、带前缀路径读取的测试。下面是一个偏通用的 AWS CLI 检查脚本，变量按实际 bucket 和 prefix 修改即可。
#!/usr/bin/env bash
set -euo pipefail
: "${S3_BUCKET:?Set S3_BUCKET}"
: "${S3_PREFIX:=teamcity-upgrade-smoke}"
KEY="${S3_PREFIX%/}/$(date +%Y%m%d-%H%M%S)-smoke.txt"
TMP_FILE="$(mktemp)"
echo "teamcity s3 smoke test $(date -Is)" > "$TMP_FILE"
aws s3 cp "$TMP_FILE" "s3://${S3_BUCKET}/${KEY}"
aws s3 cp "s3://${S3_BUCKET}/${KEY}" -
aws s3 rm "s3://${S3_BUCKET}/${KEY}"
rm -f "$TMP_FILE"
这段脚本不会证明 TeamCity 内部 bug 已经修复，但能帮助你在升级窗口内快速排除 AWS 账号、权限、bucket、prefix、网络出口这些外部变量。
升级建议：把它当作稳定性补丁，而不是例行点版本
如果你已经在 2026.1 或 2025.11 分支上，建议尽快评估 2026.1.2 或 2025.11.6。选择哪个版本取决于你当前所在分支：通常同分支补丁升级的风险更低，也更适合在短维护窗口内完成。
升级前的检查清单可以压缩成几项：
- 备份 TeamCity server 数据目录和数据库。
- 记录当前服务器版本、插件列表、agent 数量和关键 build configuration。
- 挑选 3 到 5 条代表性流水线：普通构建、可停止构建、Perforce personal build、S3 artifact 上传、AWS 凭证相关流程。
- 在预发或测试 TeamCity 上跑一轮冒烟测试。
- 升级后观察队列长度、agent 连接、artifact 上传、失败率和构建停止行为。
边界也要说清楚：摘要只说明这些版本修复了若干问题，并点名了部分修复项；它不意味着所有 Perforce、AWS 或 S3 相关失败都会消失。更稳妥的做法是把这次更新作为一次 CI 平台可靠性修补，并用你们自己的流水线覆盖真实风险点。