Gitlab Pages流水线成功后持续返回404及历史页面留存问题

问题1：URL返回404的可能原因 #

• 缓存不可靠导致历史目录丢失：你用cache保存public目录，但GitLab缓存是为加速构建设计的，并非持久化存储。不同Runner的缓存可能不共享，或缓存被自动清理，导致pages阶段执行时，public目录仅保留当前流水线的文件夹，历史流水线目录已丢失，访问旧路径自然返回404。
• Pages部署依赖artifacts而非缓存：GitLab Pages实际从pages job上传的public artifacts部署。如果pages job未将历史报告目录包含进artifacts，即便缓存里有，部署后的Pages也不会存在这些目录。
• 规则条件限制：你的pages job仅在$TASK_NAME == "load_tests"时执行，若某条流水线不满足该条件，对应报告不会部署到Pages，访问该流水线ID路径就会404。
• 路径拼写或变量替换错误：检查访问URL中的流水线ID是否与生成报告的流水线ID一致，报告文件名是否与实际生成的完全匹配（比如示例里的report_.html是否存在拼写或格式错误）。
• Pages部署延迟：少数情况GitLab Pages部署后需1-5分钟生效，刚执行完流水线就访问可能暂时404，但持续404可排除此原因。

问题2：新流水线后保留历史报告的访问权限 #

可以实现，但不能依赖缓存，需改用可靠的持久化方式：

方案1：通过历史流水线artifacts合并报告 #

每次执行pages job时，利用GitLab API拉取所有满足条件（如TASK_NAME == "load_tests"）的历史流水线报告artifacts，下载后合并到当前public目录，再上传为新的artifacts部署到Pages：

1. 在pages job中，用GitLab API获取符合条件的历史流水线ID列表。
2. 遍历每个流水线ID，下载对应报告artifacts（仅下载报告文件，避免冗余）。
3. 将下载的报告放入public/流水线ID目录。
4. 上传完整的public目录作为artifacts完成部署。

方案2：用独立Git仓库存储所有报告 #

创建专门的Git仓库存放测试报告，每次流水线生成报告后：

1. 在pages job中克隆该仓库。
2. 将当前流水线的报告放入仓库对应目录（如public/流水线ID）。
3. 提交并推送到仓库。
4. 拉取仓库完整的public目录，上传为artifacts部署到Pages。

关键注意事项 #

• 绝对不要依赖cache保留历史报告，其不可靠性会导致旧报告丢失。
• 无论采用哪种方案，都要确保pages job上传的public artifacts包含所有历史流水线的报告目录，这样GitLab Pages部署后才能保留所有路径的访问权限。

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