基础容器在Gitlab runner上是如何执行的

Question

我正在研究使用容器化环境的 CI/CD 管道。

• 在我的笔记本电脑上，一切都 运行 在包含我所有工具的 centos 容器中，而代码和配置位于共享卷上。
• 当我提交时，大部分共享卷都被推送到 master。
  • 但是，例如，我从虚拟环境中排除了任何 python 二进制文件。
• 同一个容器在 Gitlab 中用作我的 "base" 容器来执行我的一些 运行ner 阶段，以便
  • 对代码和 ansible 配置执行静态 lint 测试
  • 使用 ansible-bender 将最终产品构建为新图像

为了区分环境，我在entrypoint.sh中使用了一个基本的shell，它在容器启动时执行，在那个shell中，我使用了一个环境变量由 Gitlab 管理：CI_JOB_STAGE。但是当我 运行 本地容器而不是 运行 容器时，shell 脚本的执行方式似乎不同。这太疯狂了，因为容器的全部意义不是吗？

• 不清楚 Gitlab 在什么时候挂载 运行ner 主机和容器之间的共享
• 测试值 CI_JOB_STAGE 的条件似乎不起作用，即使在使用和 echo
打印时显示了值
• 出于某种原因，入口点在阶段执行之前和之后执行

我正在为

附上要点

• entrypoint.sh 脚本
• 容器在本地运行时的输出
  • 在这种情况下，通过检查激活二进制文件是否存在，可以看到虚拟环境已经存在，因此只需激活该环境
  • 然后检查 flask 二进制文件以查看是否需要安装要求
  • 我知道它很原始，但这只是 POC
• 运行ner 第一阶段的输出
  • 基于 shell 脚本，它不应该安装要求，因为无论如何那是阶段命令的一部分
  • 我不相信它真的这样做了，因为它过得太快了，但是消息表明它已经达到了条件
  • if [[ $CI_JOB_STAGE -eq "locally" ]] && ! test -f "./env/bin/flask"
    • 如果舞台是本地的（false：我们清楚地看到那个舞台是lint_code）
    • AND
    • flask 不存在（好吧，它不会存在，但没关系，因为前半部分已经是 false）

阶段仍然 运行 正确，但我发现这一切都很混乱。有没有人详细了解这些 运行 人的执行方式？

要点

• the entrypoint.sh for the container
• output of entrypoint when the container runs locally on my laptop
• output of entrypoint and then of the stage commands and then strangely of the entrypoint AGAIN

Answer 1

Gitlab 支持 number of executors 每个行为可能略有不同（执行程序可能会挂载自定义卷，禁止特权容器）

general workflow是：

1. 准备：创建并启动服务。
2. 作业前：克隆、恢复缓存并下载前一阶段的工件。这是一张特殊的 Docker 图片上的 运行。
3. 工作：用户构建。这是用户提供的 Docker 图片上的 运行。
4. Post-job：创建缓存，上传工件到GitLab。这是一张特殊的 Docker 图片上的 运行。

我不鼓励在 entrypoint.sh 中编写脚本。尝试将其重写为 .gitlab-ci.yml:

stages:
  - install
  - build
  - test

job 0:
  stage: .pre
  script: install some prerequisites 

job 1:
  stage: install
  script:
    - python3 -m venv env
    - source ./env/bin/activate
    - pip install -r ./dev/requirements.txt

job 2:
  stage: build
  script: make build

job 3:
  stage: test
  script: make test

它将使构建可重现且更易于阅读。您可能会使用 .pre and .post stage，只要确保您使用的 Gitlab >= 12.4.