如何阻止TeamCity无故启动AWS云代理并按需触发启动？

我之前踩过TeamCity云代理无故启停的坑，结合你的Yocto构建场景（用昂贵的大型实例，只想按需启动），给你整理两个核心问题的解决方案：

一、阻止TeamCity无故启动大型代理 #

先排查几个最容易被忽略的配置点，这些是我之前碰到过的「隐形触发源」：

• 检查云代理池的最小数量：去你的AWS Cloud Profile设置里，找到「代理池最小数量」，必须改成0。如果这个值大于0，哪怕没有任何构建任务，TeamCity会强制维持这个数量的代理运行，这大概率是你10分钟一次启停的原因。
• 排查所有隐藏的触发器：别只看你当前的构建配置，还要检查：
  • 构建配置继承的模板里有没有藏触发器；
  • 分支设置里的「自动创建分支触发器」是不是不小心开了；
  • 依赖构建的触发规则有没有误配置。
    可以在TeamCity的「构建配置」→「触发器」里，切换到「所有触发器」视图，把所有无关的触发器全删掉。
• 调整VCS根的监控策略：你已经调大了检查间隔，但还要确认：
  • 所有VCS根的「静默监控」（实时监听分支变化）是不是关了？如果开着，哪怕间隔设得大，TeamCity还是会实时检测提交，可能误触发代理启动；
  • 只给后面要用到的「小型触发代理」的VCS根保留短间隔，大型代理的VCS根直接把检查间隔设成1小时甚至更久。
• 验证代理停止的状态同步：如果日志里有类似「Agent not found, starting new instance」的错误，说明TeamCity没正确获取到AWS实例的停止状态，导致误判需要重启。这时候要检查：
  • TeamCity的IAM权限有没有ec2:DescribeInstances等实例状态查询权限；
  • 调整Cloud Profile里的「实例状态同步间隔」，比如改成30秒，让TeamCity更快感知实例已经停止。

二、实现Git提交自动启动大型代理（代理端打标签） #

因为你需要在代理端完成Git打标签，不能用服务器端检出，所以用「小型代理做触发+大型代理做构建」的分层方案最适合：

1. 配置小型触发代理的Cloud Profile #

• 用廉价的小型实例（比如t3.micro）创建单独的Cloud Profile；
• 设置「代理池最小数量」为0，「闲置停止时间」设成10分钟（确保触发后很快停止，不浪费钱）；
• 给这个Profile绑定专门的代理标签（比如trigger-agent），方便后续构建配置指定代理。

2. 创建触发型构建配置 #

这个配置只做三件事：监听Git提交、代理端打标签、触发大型构建：

• 绑定小型代理：在构建配置的「代理要求」里，添加agent.label:trigger-agent，确保只有小型代理能运行它；
• 添加VCS触发器：监听你需要触发构建的Git分支（比如main、develop），设置「触发规则」为每次提交都触发；
• 配置构建步骤：
  1. 第一步：设置VCS检出方式为「代理端检出」，拉取最新代码；
  2. 第二步：执行Git打标签命令，比如：

     git tag -a v%build.number% -m "Auto tag from build %build.number%"
     git push origin v%build.number%
     

     这里用TeamCity的内置参数%build.number%作为标签版本号，你也可以改成自定义的规则；
  3. 第三步：添加「触发构建」步骤，选择你的大型Yocto构建配置，设置只有当前构建成功时才触发。
• 优化配置：给这个构建配置设置「构建队列限制」为1，避免短时间多次提交导致启动多个小型代理。

3. 配置大型Yocto构建配置 #

• 绑定你的大型实例Cloud Profile，「代理池最小数量」设为0，「闲置停止时间」设为5分钟，「构建完成后停止代理」打开；
• 移除所有VCS触发器：确保这个配置只会被触发型构建启动，不会自己无故启动；
• 设置代理要求：添加大型代理的专属标签（比如yocto-build-agent），确保只有大型实例代理能运行它；
• 保持VCS检出方式为「代理端检出」，满足Yocto构建的需求。

这样一套配置下来，既能彻底杜绝大型代理无故启停，又能实现Git提交时自动触发构建，还完美满足了代理端打标签的要求。

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