TeamCity未发布内部工件（ArtifactsCachePublisher & WebPublisher）问题

刚做完服务器迁移就碰到这种卡壳的情况，确实挺闹心的。结合你描述的新旧代理日志差异——新代理拉取代码正常，但直接跳过核心构建步骤就结束，旧代理完全正常——我整理了几个针对性的排查方向，应该能帮你定位问题：

1. 先查工作目录的权限问题 #

新服务器上的TeamCity代理服务账号，可能对工作目录、临时目录没有足够的读写权限：

• 找到代理的工作目录（比如你日志里的C:\BuildAgent\work）和临时目录C:\BuildAgent\temp，右键文件夹→「属性」→「安全」标签
• 确认运行TeamCity Agent服务的账号（默认是Local System，也可能是你指定的域账号）拥有读取、写入、修改的权限，最好直接给「完全控制」权限测试
• 可以手动在这些目录里新建个文本文档，验证账号能不能正常读写

2. 核对代理配置文件的关键参数 #

新代理的buildAgent.properties配置可能和旧代理有差异，导致工件发布流程异常：

• 打开新代理安装目录下的conf\buildAgent.properties文件
• 重点核对这几个参数，和旧代理的配置保持一致（除了服务器地址这类必须改的）：
  • agent.work.dir：工作目录路径是否正确
  • agent.temp.dir：临时目录路径是否存在、空间充足
  • artifacts.cache.dir：工件缓存目录的配置是否正确
• 改完配置后记得重启TeamCity Agent服务

3. 确认代理和服务器版本完全匹配 #

TeamCity对代理和服务器的版本一致性要求很高，版本不匹配很容易出现诡异的流程跳过：

• 登录TeamCity服务器，进入「Agents」页面，查看新代理的版本号
• 对比服务器的版本号（在服务器页面右下角可以看到），必须完全一致（比如服务器是2023.05，代理也得是2023.05）
• 如果版本不对，卸载新代理，去服务器的「Agents」页面下载对应版本的代理安装包重新部署

4. 扒代理日志找隐藏报错 #

构建日志只显示了表面流程，代理本身的日志里可能藏着关键错误：

• 打开新代理的logs目录，重点看teamcity-agent.log和teamcity-agent-windows.log（Windows环境）
• 搜索ArtifactsCachePublisher、WebPublisher或者build finished附近的内容，大概率能找到具体报错——比如权限拒绝、路径不存在、连接超时之类的
• 比如看到Failed to publish artifacts: Access is denied，就直接锁定权限问题了

5. 检查服务器端的代理规则限制 #

有可能服务器端给新代理设置了限制，导致它没法执行某些步骤：

• 进入TeamCity服务器的「Agents」页面，选中新代理，查看「Agent Features」，确认必要的构建工具（比如Git、MSBuild）都已经配置
• 再打开对应的Build Configuration，看「Agent Requirements」标签，有没有设置只匹配旧代理的规则（比如旧代理的特定标签、操作系统版本），如果有的话把新代理也加入进去

6. 做个简单的测试构建验证 #

可以创建一个极简的测试Build Configuration，验证新代理的工件发布功能：

• 新建一个配置，设置拉取一个简单的GitHub仓库，然后添加一个步骤：创建一个文本文件
• 把这个文本文件设置为构建工件，触发构建看新代理能不能正常执行步骤、发布工件
• 如果这个测试能成功，说明问题出在原有配置的某个细节上，再回头对比旧代理的配置差异

内容的提问来源于stack exchange，提问作者Kerbol