Azure DevOps：管道运行失败后如何执行工作区清理步骤

1. 构建异常失败时强制触发工作区清理 #

你之前使用的succeedOrFailed()条件仅在作业正常调度完成（无论成功失败）时生效，当触发超时、磁盘占满等导致代理强制终止作业的场景时，作业内部步骤不会被调度，要覆盖这类场景可以用两种方案：

• 配置代理级别的作业后置钩子：找到代理安装目录下的externals目录，新增post-job.ps1（Windows）或post-job.sh（Linux/macOS）脚本，在脚本中写入清理当前作业工作区的逻辑，该脚本会在代理完成任意作业（含异常终止的作业）后强制执行
• 若仅需要覆盖超时场景，可在YAML中给清理步骤显式设置condition: always()，同时调整作业超时时间的软阈值，在硬超时触发前先触发软超时执行清理步骤

2. 修复工作区重复创建问题 #

配置了clean: all仍然新建工作区，通常是代理判断现有工作区不可用导致，可逐一排查修复：

• 显式指定管道工作区名称，避免代理自动生成哈希名导致目录不匹配，YAML配置参考：

  jobs:
  - job: Build
    workspace:
      name: MyFixedWorkspaceName
      clean: all
  

• 检查代理工作目录的权限，确保代理运行账号对工作根目录（默认是代理安装路径下的_work目录）有读写、删除、修改权限
• 删除工作根目录下损坏的工作区标识文件：如果旧工作区目录下的.agent标识文件损坏，代理会直接创建新目录，可定期清理无锁的旧标识文件
• 禁用工作区保留配置：将管道变量Agent.RetainWorkingDirectory设为false，避免异常退出后代理强制保留工作区

3. 更安全的定时清理替代方案 #

替代cron直接执行rm -rf的方案，可创建专属的维护管道：

• 管道配置为定时触发，优先级设为最高，执行前先暂停所有普通构建管道的调度
• 清理逻辑中增加两项校验：① 检查工作区目录下是否存在代理运行时的.lock文件，存在则判定为正在使用跳过删除；② 仅删除最后访问时间超过7天的工作区目录
• 清理完成后自动恢复普通构建管道的调度

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