我有一个像这样的 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 加载图像。不幸的是,访问特定作业工件的语法以查询字符串结尾。这实际上意味着我们不能将工作工件作为徽章链接。
最流行的解决方法是滥用 Gitlab 的页面功能将工件存储为静态内容。从那里我们可以获得不包含查询字符串的工件的干净 URL。
我的困惑涉及 .gitlab-ci.yml 中定义的“页面”作业背后的底层机制。这里的官方文档非常稀少。有一百万个使用各种框架部署实际网页的示例,但我对其中任何一个都不感兴趣,因为我只是使用我的项目的“页面”进行文件托管。
假设似乎是我想在管道末端部署我的页面。但是,我想在管道开始附近上传 shellcheck 和 pylint 工件。此外,即使管道阶段失败,我也希望上传这些工件。
从语法上讲,页面作业看起来与任何其他作业相同。没有什么可以描述它是如何被 Gitlab 的内部神奇地拾取的。这给我留下了以下问题:
- 我可以将阶段从“部署”更改为“签入测试”,还是部署阶段是 Gitlab 在解析页面作业时寻找的隐藏魔法的一部分?
- 如果我被绑定到部署阶段,我是否可以重新安排阶段以使其在管道中更早出现而不会破坏魔力?
- 页面作业是从本地机器部署工件(作业的默认行为),还是列出的路径来自先前作业已经上传到 Gitlab 管道的工件?
- 如果页面作业仅在本地查找工件,我如何确保它与早期作业在同一台机器上运行,以便找到它们产生的工件?让我们假设 Gitlab 执行器都来自具有相同标签的池,并且没有单独标记。
- 是否有机会让页面作业在最初生成工件的同一个 Docker 容器中运行?