Perforce change-content触发器内能否创建变更列表？

我计划实现一款Perforce change-content 触发器，核心逻辑是调用clang-format校验提交至Perforce Depot的文件是否符合代码格式化规范，将未通过校验的文件移入新建变更列表（CL），同时附带对应文件需格式化的提示信息。

目前我对该方案的可行性存在疑问：

• 编写的实现脚本在本地命令行环境下运行完全正常，逻辑为：调用p4 change创建新CL、调用p4 reopen将目标文件移入该CL，若CL为空则执行p4 change -d删除空CL
• 但在触发器实际调用场景下，仅当脚本中加入p4 submit命令时才成功创建过变更列表，该操作还递归生成了3500+个变更列表

现咨询：是否可在change-content触发器的执行流程中正常创建变更列表？

首先给出明确结论：不建议、也基本无法在change-content触发器执行流程中完成「新建CL、将未通过校验的文件移入新CL」这类操作，你遇到的异常是触发器运行机制与预期逻辑直接冲突导致的，具体原因和可行实现方案如下：

• change-content触发器的运行时机有严格限制：该触发器触发时，触发它的原始提交事务还未完成，提交涉及的所有文件都被当前事务加锁，所有事务上下文绑定在正在提交的CL上，触发器进程继承Perforce服务进程的运行权限，和你手动在本地客户端执行命令的用户会话上下文完全隔离。你本地脚本能正常跑通，是因为本地环境已经配置了P4USER/P4CLIENT/P4PORT等环境变量，有完整的用户登录态、工作区权限；而触发器运行时默认没有绑定对应用户的工作区、登录态，直接调用p4系列命令本质是在服务端无客户端上下文的环境操作，不可能按预期生效。另外提交事务持有的文件锁优先级高于普通用户操作，此时你根本无法对提交中的文件执行p4 reopen——reopen要求文件处于工作区待提交的未锁定状态，这一条件在change-content触发时完全不满足。
• 你遇到的「加p4 submit就递归生成3500+CL」是Perforce触发器开发的典型问题：在change-content触发器中执行p4 submit会发起新的提交事务，再次触发change-content触发器，新的触发器实例又会执行p4 submit，形成无限递归，直到触发服务端资源限制才会终止。
• 要实现clang-format代码格式化校验的需求，推荐按以下逻辑实现，稳定性远高于操作CL的方案：
  • 在change-content触发器中直接读取提交的文件内容，调用clang-format做格式校验，不要在触发器内尝试修改用户工作区状态、移动文件、操作CL，这类涉及用户本地工作区的操作服务端侧没有执行权限。
  • 校验不通过时直接让触发器返回非0退出码，同时在标准输出打印明确的错误信息，列出所有不符合规范的文件、对应的格式化命令，Perforce会直接将错误信息返回给提交操作的用户，当前提交事务会直接回滚，不会合入Depot。
  • 如果一定要实现「未通过校验的文件自动移入新CL」的交互，不要把逻辑放在服务端触发器中：可以搭配change-commit触发器（提交成功入库后触发，此时事务锁已经释放）加客户端侧脚本实现，提交完成后触发器记录不符合规范的文件信息，用户在本地客户端执行配套脚本拉取列表，在本地用户上下文下完成创建CL、移入文件的操作——服务端触发器没有权限操作用户本地工作区的待提交CL，这类操作只能在客户端侧执行。
• 额外提醒：如果确实需要在触发器中调用p4命令，必须在命令中显式指定-u（对应用户名）、-p（Perforce服务地址端口）、-c（对应工作区名）参数，不能依赖运行环境的默认环境变量，否则必然出现上下文不匹配的问题。

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