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文件渲染为badges。

Gitlab徽章工具需要一个指向图像文件的URL。无法从带有查询字符串的URL加载图像。不幸的是，用于访问特定作业工件ends in a query string的语法。这实际上意味着我们不能将工作伪像链接为徽章。

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

我的困惑涉及.gitlab-ci.yml中定义的“页面”作业背后的潜在机制。这里的official documentation非常稀疏。 a million examples可以用于部署具有各种框架的实际网页，但是我对它们中的任何一个都不感兴趣，因为我只是将项目的“页面”用于文件托管。

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

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

我可以将阶段从“部署”更改为“测试中”，还是部署阶段是Gitlab在解析页面作业时寻找的隐藏魔术的一部分？
如果我受困于部署阶段，是否可以重新安排阶段以使其早日发布，而又不会破坏魔力？
页面作业是从本地计算机上部署工件（作业的默认行为）还是列出的路径来自早先的作业已经上传到Gitlab管道的工件？
如果pages作业仅在本地查找工件，我如何确保它与早期作业在同一台机器上运行，以便找到它们产生的工件？假设Gitlab执行程序全部来自具有相同标签的池，并且没有单独进行标签。
是否有可能让页面作业在最初产生工件的同一Docker容器中运行？

Answer 1

GitLab页面的神奇之处在于工作的名字。它必须被命名为“页面”，仅此而已。可以将作业移到不同的阶段。作业“ pages”成功完成后，就会有一种特殊的作业，称为“ pages：deploy”。即使您更改运行“页面”作业的阶段，该作业也会显示在部署阶段。

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

除此之外，“页面”作业类似于GitLab中的正常作业。如果您需要其他作业的工件，则可以使用工件和依赖项来获得它们：

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

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

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

1 个答案: