Azure DevOps经典发布管道SSH任务因Docker Compose STDERR失败问询

1. 为何docker-compose返回0退出码却在STDERR写入信息？ #

很多CLI工具的设计逻辑里，STDERR并非只用来输出致命错误，还会用来输出警告、诊断日志、非结构化的状态提示这类内容。这么做是为了把真正的结构化输出（比如命令执行后的有效数据）留给STDOUT，方便用户通过重定向STDOUT来保存有用结果，而不会被日志类信息干扰。

docker-compose就是遵循这个设计：当命令整体执行成功（比如容器正常启动/重建），即使过程中有一些非致命的提示（比如容器重启的通知、配置项的警告），它会返回0的成功退出码，但把这些提示信息输出到STDERR，而非STDOUT。

2. 解决方案 #

针对Azure DevOps SSH任务的这个判定逻辑，有几个实用的解决办法：

• 修改命令，重定向STDERR到STDOUT
  把原命令改成：

  cd /home/asem/platform/$(ServiceName) && sudo docker-compose up -d --force-recreate 2>&1
  

  这样所有输出（包括STDERR的提示）都会被转到STDOUT，Azure DevOps就不会把这些内容判定为错误。如果命令真的执行失败，退出码会是非0，任务依然会正常失败，不影响真正的错误检测。

• 关闭SSH任务的“Fail on STDERR”选项
  在经典发布管道的SSH任务配置界面里，找到“Fail on STDERR”的开关，将其设置为关闭。这样任务只会根据命令的退出码判断成功与否，忽略STDERR的输出内容。这是最直接的配置层面解决方法，不需要修改命令。

• 过滤STDERR输出（不推荐）
  如果确定STDERR里的内容都是无关提示，可以直接丢弃STDERR：

  cd /home/asem/platform/$(ServiceName) && sudo docker-compose up -d --force-recreate 2>/dev/null
  

  但这个方法会丢失所有STDERR信息，包括真正的致命错误，所以只在你明确知道输出内容的情况下使用。

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