如何避免在Gitlab CI中重新安装每个作业的依赖项

Question

我正在使用Gitlab CI 8.0和gitlab-ci-multi-runner 0.6.0.我有一个.gitlab-ci.yml类似于以下的文件:

before_script:
  - npm install

server_tests:
  script: mocha

client_tests:
  script: karma start karma.conf.js

这有效,但这意味着在每个测试作业之前独立安装依赖项.对于具有许多依赖项的大型项目,这会增加相当大的开销.

在Jenkins中,我将使用一个作业来安装依赖项,然后对它们进行TAR,然后创建一个构建工件,然后将其复制到下游作业.类似的东西可以与Gitlab CI一起使用吗？有推荐的方法吗？

Answer 1

更新:我现在推荐使用artifacts短片expire_in.这是优越的,cache因为它只需要为每个管道编写一次工件,而缓存在每个工作之后更新.此外,缓存是每个运行程序,因此如果您在多个运行程序上并行运行作业,则无法保证填充,与集中存储的工件不同.

Gitlab CI 8.2添加了运行程序缓存,允许您在构建之间重用文件.但是我发现这很慢.

相反,我使用一些shell脚本实现了我自己的缓存系统:

before_script:
  # unique hash of required dependencies
  - PACKAGE_HASH=($(md5sum package.json))
  # path to cache file
  - DEPS_CACHE=/tmp/dependencies_${PACKAGE_HASH}.tar.gz
  # Check if cache file exists and if not, create it
  - if [ -f $DEPS_CACHE ];
    then
      tar zxf $DEPS_CACHE;
    else
      npm install --quiet;
      tar zcf - ./node_modules > $DEPS_CACHE;
    fi

这将在您的每个作业之前运行,.gitlab-ci.yml并且只安装您的依赖项(如果package.json已更改或缓存文件丢失)(例如,首次运行,或手动删除文件).请注意,如果您在不同的服务器上有多个运行程序,它们将各自拥有自己的缓存文件.

您可能希望定期清除缓存文件以获取最新的依赖项.我们使用以下cron条目执行此操作:

@daily               find /tmp/dependencies_* -mtime +1 -type f -delete

Answer 2

如今更好的方法是利用文物.

在以下示例中,一旦阶段成功完成,该node_modules/目录即可立即用于lint作业build.

build:
  stage: build
  script:
    - npm install -q
    - npm run build
  artifacts:
    paths:
      - node_modules/
  expire_in: 1 week

lint:
  stage: test
  script:
    - npm run lint

Answer 3

从文档：

• cache:用于项目依赖的临时存储。对于保留中间构建结果（如jar或apk文件）没有用。缓存旨在通过保留诸如依赖项（例如，npm 包、Go 供应商包等）之类的东西来加速给定作业的后续运行的调用，因此不必从公众那里重新获取它们互联网。虽然可以滥用缓存在阶段之间传递中间构建结果，但在某些情况下，工件更适合。

• artifacts：用于将在阶段之间传递的阶段结果。Artifacts 被设计为上传一些编译/生成的构建位，它们可以被任意数量的并发 Runners 获取。它们保证可用，并且可以在作业之间传递数据。它们也可以从 UI 下载。工件只能存在于相对于构建目录的目录中，并且指定不符合此规则的路径会触发不直观和不合逻辑的错误消息（在https://gitlab.com/gitlab-org/gitlab-ce上讨论了增强功能/问题/15530）。在下一阶段作业开始之前，工件需要上传到 GitLab 实例（不仅是 GitLab 运行程序），因此您需要在投入时间之前仔细评估您的带宽是否允许您从与阶段和共享工件的并行化中获利在设置的更改中。

所以，我使用cache. 当不需要更新缓存时（例如测试作业中的构建文件夹），我使用policy: pull（参见此处）。

Answer 4

我认为不推荐\xc2\xb4s，因为同一阶段的所有作业都可以并行执行。

\n\n

\n
1. 首先，所有构建作业都是并行执行的。
\n
2. 如果构建的所有作业都成功，​​则并行执行测试作业。
\n
3. 如果测试的所有作业都成功，​​则部署作业将并行执行。
\n
4. 如果部署的所有作业都成功，​​则提交标记为成功。
\n
5. 如果之前的任何作业失败，则提交将被标记为失败，并且不会执行后续阶段的作业。
\n

\n\n

我在这里读过：

\n\n

http://doc.gitlab.com/ci/yaml/README.html

\n