Gitlab 的“页面”工作在内部是如何工作的？

Question

我有一个像这样的 Gitlab 项目（.gitlab-ci.yml）：

# Sub-jobs listed as comments
stages:
  - check-in-tests
      # shellcheck
      # pylint
      # unit-tests
  - several-other-things
      # foo
      # bar
      # baz
  - release
      # release

# Run some shell code static tests and generate logs/badges
shellcheck:
  stage: check-in-tests
  script:
    - bash run_shellcheck.sh
  artifacts:
    paths:
      - logs/shellcheck.log
      - logs/shellcheck.svg

# Run some python code static tests and generate logs/badges
pylint:
  stage: check-in-tests
  script:
    - bash run_pylint.sh
  artifacts:
    paths:
      - logs/pylint.log
      - logs/pylint.svg

# <snip>

在我的项目页面上，我想将签入测试期间生成的 .svg 文件呈现为badages。

Gitlab 徽章工具需要图像文件的 URL。它无法从带有查询字符串的 URL 加载图像。不幸的是，访问特定作业工件的语法以查询字符串结尾。这实际上意味着我们无法将工作工件作为徽章链接到。

最流行的解决方法是滥用 Gitlab 的页面功能将工件存储为静态内容。从那里我们可以获得不包含查询字符串的工件的干净 URL。

我的困惑涉及 .gitlab-ci.yml 中定义的“页面”作业背后的底层机制。这里的官方文档非常稀疏。有一百万个使用各种框架部署实际网页的示例，但我对其中任何一个都不感兴趣，因为我只是使用项目的“页面”进行文件托管。

假设似乎是我想在管道的末尾部署我的页面。但是，我想在管道开头附近上传 shellcheck 和 pylint 工件。此外，即使管道阶段失败，我也希望上传这些工件。

从语法上讲，页面作业看起来与任何其他作业相同。没有什么可以描述它是如何被 Gitlab 的内部神奇地拾取的。这给我留下了以下问题：

• 我可以将阶段从“部署”更改为“签入测试”吗？或者部署阶段是否是 Gitlab 在解析页面作业时寻找的隐藏魔法的一部分？
• 如果我与部署阶段相关，我可以重新安排这些阶段，使其在管道中更早出现，而不破坏魔力吗？
• 页面作业是否从本地计算机部署工件（作业的默认行为），或者列出的路径是否来自已由早期作业上传到 Gitlab 管道的工件？
• 如果页面作业仅在本地查找工件，我如何确保它与早期作业在同一台计算机上运行，​​以便找到它们生成的工件？我们假设 Gitlab 执行程序都来自具有相同标签的池，并且没有单独标记。
• 是否有机会让页面作业在最初生成工件的同一个 Docker 容器中运行？

Answer 1

GitLab 页面的魔力在于工作的名称。它必须被命名为“pages”，仅此而已。可以将工作转移到不同的阶段。一旦作业“pages”成功完成，就会出现一种特殊类型的作业，称为“pages:deploy”。即使您更改运行“pages”作业的阶段，该作业也会显示在部署阶段。

如果您在早期阶段有页面作业，则后期阶段的作业可能会失败，但“pages:deploy”作业仍将运行并更新 GitLab 页面。

除此之外，“页面”工作就像 GitLab 中的正常工作一样。如果您需要其他作业的工件，您可以通过使用工件和依赖项来获取这些工件：

https://docs.gitlab.com/ee/ci/yaml/#dependency

“pages”作业应创建一个名为“public”的文件夹，并将该文件夹作为工件提供。