我碰到过好几次类似的GitLab Pages部署后404的情况，咱们一步步来排查可能的问题：

• 确认Pages的部署来源设置
  进入项目的Settings -> Pages页面，检查「Deployment source」是不是设置为CI/CD pipeline。如果之前设置成了某个特定分支的public目录，那CI生成的工件就不会被用来部署，自然访问会404。

• 检查deploy-pages作业的运行分支
  你的CI配置里except: - tags，但要注意：只有默认分支（一般是main或master）的Pages部署才会映射到https://my-group.gitlab.io/my-project这个主地址。如果是在其他分支（比如feature分支）运行的流水线，生成的Pages只能通过临时路径访问，格式是https://my-group.gitlab.io/-/my-project/-/jobs/[作业ID]/artifacts/public/index.html。你可以去流水线的deploy-pages作业详情里找到这个临时链接，先验证报告能不能正常打开。

• 确认public目录的文件结构
  GitLab Pages默认会找public目录下的index.html作为首页。你可以去deploy-pages作业的工件里，查看public目录下有没有index.html文件——毕竟你的yarn test --coverage生成的coverage目录里必须包含这个入口文件，mv coverage/ public/后才能被Pages识别。如果coverage里的入口文件名字不是index.html，那需要修改文件名或者配置Pages的默认首页。

• 查看Pages的部署记录
  同样在Settings -> Pages页面，往下翻可以看到「Deployments」列表，检查有没有状态为active的部署记录，对应的流水线是不是你刚才运行的那个。如果没有成功的部署记录，那说明deploy-pages作业的工件没有被正确用来部署，可能需要重新触发流水线。

• 确认Pages功能已启用
  还是在Settings -> Pages页面，顶部如果显示「Pages is enabled for this project」才是正常的。如果没启用，点击「Enable Pages」按钮开启功能，然后重新运行流水线。

另外，你可以先通过deploy-pages作业的工件预览链接验证coverage报告是否正常，比如在作业详情里点击「Browse」按钮进入public目录，直接打开index.html看能不能加载。如果这里能正常显示，那问题大概率出在Pages的部署设置或者分支匹配上。

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