GitLab Uploads用途、与Job Artifacts对比及管理方法咨询

1. GitLab Uploads的适用场景？存储编译产物选Uploads还是Job Artifacts？ #

• GitLab Uploads的适用场景：
  • 主打非流水线产出的零散文件上传，比如给issue、合并请求加的附件，手动生成的项目配置文件、补充文档这类和项目内容直接关联，但不是CI/CD流水线自动输出的文件。
  • 上传后的文件能直接通过浏览器访问，适合快速给团队成员共享小文件。
• 存储编译产物优先选Job Artifacts：
  • Job Artifacts是专为CI/CD流水线设计的，支持设置过期时间自动清理，不会占着存储不放。
  • 能和流水线任务绑定，在GitLab的流水线页面就能直接查看、下载，还支持跨Job依赖传递（比如后续测试Job可以直接用前面编译Job的产物）。
  • 支持批量存储、压缩，对编译包、测试报告这类流水线产出的批量文件更友好。
  • Uploads没有自动过期机制，也没法和流水线关联，长期存编译产物会导致存储冗余，管理起来非常麻烦。

2. 如何管理项目中的所有Uploads（列出、删除）？ #

GitLab官方目前没有提供直接批量管理Uploads的API，但可以用这些方式处理：

• 列出Uploads：
  • 如果是自己通过API上传的，建议手动记录每个文件的返回URL和相关信息，存在项目的配置文档或者内部记录里。
  • 针对issue/合并请求里的Uploads，只能在对应issue/MR的附件列表里逐个查看，没法批量导出整个项目的Uploads清单。
• 删除Uploads：
  • 单个文件删除：用上传成功后返回的文件路径构造DELETE请求，比如返回的文件路径是/uploads/abc123/myfile.txt，执行以下命令即可删除：

    curl --request DELETE \
      --header "Private-Token: ${MY_ACCESS_TOKEN}" \
      "${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/uploads/abc123/myfile.txt"
    

  • issue/MR里的附件：直接在对应issue/MR页面手动删除即可。
  • 目前没有官方的批量删除工具，只能逐个处理；如果有管理员权限，也可以直接操作GitLab的存储目录，但这种方式风险高，容易破坏数据一致性，不推荐。

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