两个Azure发布管道中相同Git克隆任务表现差异原因咨询

以下是两个管道可能存在的核心差异点，以及对应的输出解析控制设置：

1. PowerShell任务的错误处理配置 #

• $ErrorActionPreference 环境变量：两个管道的PowerShell执行环境中，该变量的取值可能不同。比如一个设为Stop（遇到任何错误输出立即终止任务），另一个设为Continue/SilentlyContinue。Git克隆时的红色字体输出通常是警告类信息，会被输出到stderr；若$ErrorActionPreference = Stop，PowerShell会将stderr的内容判定为终止级错误，导致管道无提示退出；添加*> $null会屏蔽所有输出（包括stderr），自然就不会触发这个终止逻辑。
• "Fail on standard error"任务选项：Azure DevOps的PowerShell任务里有一个开关选项，控制是否将标准错误（stderr）输出视为任务失败。如果其中一个管道开启了这个选项，Git的警告信息（红色输出）会被判定为错误导致任务失败；另一个管道关闭了该选项，就能正常执行。而*> $null会把stderr也重定向，所以即使开启该选项也不会触发失败判定。

2. 管道日志记录级别设置 #

两个管道的日志详细程度可能不同（比如一个设为「详细」，一个设为「正常」）。日志级别较高时，Azure DevOps可能会把Git的进度类输出误判为错误信息；重定向输出后，这些信息被屏蔽，就不会触发错误判定逻辑。

3. PowerShell版本差异 #

两个管道使用的PowerShell版本可能不一致（比如一个用PowerShell 5.1，一个用PowerShell 7），不同版本对输出重定向的处理逻辑有细微区别。比如PowerShell 7中*> $null的行为和5.1略有不同，可能导致在某个版本下必须通过重定向才能规避错误判定。

4. 任务工作目录或Git环境变量差异 #

尽管目标服务器相同，但两个管道的PowerShell任务工作目录可能不同，或者Git相关环境变量（如GIT_TRACE、GIT_CURL_VERBOSE）设置有差异。这些变量会让Git输出更多调试信息到stderr，进而触发管道的错误判定；重定向输出后，这些额外信息被屏蔽，任务即可成功执行。

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