JFrog Artifactory批量删文件过慢，如何高效清理旧UI测试截图？

方案1：原子目录替换（推荐） #

核心思路是先将新截图上传到临时目录，完成后通过Artifactory的移动API原子替换目标PR的正式目录，彻底避免删除操作与上传操作的冲突。

1. 上传新截图到临时目录
   每次运行测试时，将截图上传到带唯一标识（如构建ID、时间戳）的临时文件夹：

# 示例：用BUILD_ID作为临时目录后缀
curl -sSf -u "$artifactoryUser:$artifactoryPassword" \
  -T "screenshots/*" \
  "$artifactoryUrl/pr-$PR_NUMBER/temp-$BUILD_ID/"

2. 原子替换正式目录
   上传完成后，调用Artifactory的移动API将临时目录替换为PR的正式目录（如latest），该操作是原子性的，不会出现新旧文件混合的情况：

# 可选：将旧的正式目录移到归档，用于临时回溯
curl -sSf -u "$artifactoryUser:$artifactoryPassword" \
  -X POST "$artifactoryUrl/api/move/pr-$PR_NUMBER/latest" \
  -H "Content-Type: application/json" \
  -d "{\"to\": \"pr-$PR_NUMBER/archive-$(date +%Y%m%d%H%M%S)\", \"overwrite\": false}" &

# 将临时目录替换为最新正式目录
curl -sSf -u "$artifactoryUser:$artifactoryPassword" \
  -X POST "$artifactoryUrl/api/move/pr-$PR_NUMBER/temp-$BUILD_ID" \
  -H "Content-Type: application/json" \
  -d "{\"to\": \"pr-$PR_NUMBER/latest\", \"overwrite\": true}"

3. 异步清理归档目录
   后台异步删除归档的旧目录，不影响当前测试结果的可用性：

# 清理7天前的归档目录（示例）
curl -sSf -u "$artifactoryUser:$artifactoryPassword" \
  "$artifactoryUrl/pr-$PR_NUMBER?list&deep=0" | grep "archive-" | while read dir; do
    dir_date=$(echo "$dir" | sed 's/archive-//')
    if [ $(date -d "$dir_date" +%s) -lt $(date -d "-7 days" +%s) ]; then
      curl -sSf -u "$artifactoryUser:$artifactoryPassword" -X DELETE "$artifactoryUrl/pr-$PR_NUMBER/$dir" &
    fi
  done

优点：完全避免删除与上传的冲突，原子替换保证目录始终是完整的最新截图集，归档机制可临时保留历史用于回溯。
缺点：需要额外管理临时和归档目录，逻辑稍复杂。

方案2：基于构建信息的自动清理 #

利用Artifactory的构建关联功能，将截图与构建绑定，通过构建清理规则自动删除旧构建的文件。

1. 上传截图并关联构建
   上传截图后，提交Build Info到Artifactory，将截图文件与当前构建（如pr-$PR_NUMBER-$BUILD_ID）关联：

# 收集所有上传的截图路径
screenshot_files=$(find screenshots -type f | sed "s|screenshots/|pr-$PR_NUMBER/latest/|")
# 构建Build Info JSON
cat > build_info.json << EOF
{
  "name": "pr-screenshots",
  "number": "$PR_NUMBER-$BUILD_ID",
  "modules": [
    {
      "artifacts": [
        $(printf '{"uri": "%s"}' "${screenshot_files[@]}" | paste -sd "," -)
      ]
    }
  ]
}
EOF
# 提交Build Info
curl -sSf -u "$artifactoryUser:$artifactoryPassword" \
  -X POST "$artifactoryUrl/api/build" \
  -H "Content-Type: application/json" \
  -d @build_info.json

2. 设置构建清理规则
   在Artifactory后台配置构建清理策略：

• 选择构建名称pr-screenshots
• 设置分组规则：按PR号分组（通过构建编号前缀$PR_NUMBER-识别）
• 保留策略：每个分组保留最新1个构建
• 触发方式：可设置定时清理或构建完成后自动清理

优点：无需手动编写删除逻辑，Artifactory自动管理旧文件，避免人为操作失误。
缺点：需要熟悉Artifactory的构建信息和清理规则配置，首次设置成本稍高。

方案3：定向删除旧文件 #

若坚持使用原目录结构，可只删除旧的截图文件（而非整个目录），避免新上传文件被误删。

1. 筛选并删除旧文件
   列出目录中所有不属于当前构建的文件，批量异步删除：

# 获取目录下所有文件，过滤掉当前BUILD_ID标记的文件
curl -sSf -u "$artifactoryUser:$artifactoryPassword" \
  "$artifactoryScreenshotFolderUrl?list&deep=1" | grep -v "$BUILD_ID" > old_files.txt

# 批量删除旧文件（后台异步执行）
while read file_path; do
  curl -sSf -u "$artifactoryUser:$artifactoryPassword" -X DELETE "$artifactoryUrl/$file_path" &
done < old_files.txt

注：需确保本次测试的截图文件名包含唯一标识（如step1-$BUILD_ID.png），避免与旧文件重名。

优点：逻辑简单，无需修改上传路径。
缺点：若测试中途失败，旧文件可能未完全删除，导致新旧截图混杂；批量删除仍可能耗时，但不会影响新上传文件。

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