为什么 GitLab Ci 找不到我的缓存文件夹？

Question

我的 GitLab 中运行着一个 CI 作业列表，但缓存未按预期工作：

这就是我的文档生成工作的结束方式：

[09:19:33] Documentation generated in ./documentation/ in 4.397 seconds using gitbook theme
Creating cache angular...
00:02
WARNING: frontend/node_modules: no matching files  
frontend/documentation: found 136 matching files   
No URL provided, cache will be not uploaded to shared cache server. Cache will be stored only locally. 
Created cache
Job succeeded

然后我开始部署作业（到 GitLab Pages），但它失败了，因为它找不到文档文件夹：

$ cp -r frontend/documentation .public/frontend
cp: cannot stat 'frontend/documentation': No such file or directory

这是这一代的缓存配置：

generate_docu_frontend:
  image: node:12.19.0
  stage: build
  cache:
    key: angular
    paths:
      - frontend/node_modules
      - frontend/documentation
  needs: ["download_angular"]

这是用于部署的：

deploy_documentation:
  stage: deploy
  cache:
    - key: angular
      paths:
        - frontend/node_modules
        - frontend/documentation
      policy: pull
    - key: laravel
      paths:
        - backend/vendor
        - backend/public/docs
      policy: pull

有谁知道为什么我的文档文件夹丢失了？

Answer 1

作业输出中的消息No URL provided, cache will be not uploaded to shared cache server. Cache will be stored only locally.仅意味着您的运行程序没有使用Amazon S3来存储缓存或类似Minio的内容。

如果没有 S3/Minio，缓存仅存在于首先运行作业并缓存资源的运行器上。这意味着下次作业运行并且它碰巧被不同的运行程序拾取时，它将没有缓存。在这种情况下，您会遇到这样的错误。

有几种方法可以解决这个问题：

1. 配置您的跑步者以使用 S3/Minio（Minio 是一个开源、免费使用的许可证，如果您有兴趣自己托管它）。
2. 仅使用一个运行程序（这不是一个很好的解决方案，因为通常更多的运行程序意味着更快的管道，这会大大减慢速度，尽管它可以解决缓存问题）。
3. 使用tags。标签用于确保作业在特定的运行器上运行。举例来说，您的 10 个运行者中有 1 个可以访问您的生产服务器，但所有人都可以访问您的较低环境服务器。您的较低环境作业可以在任何运行器上运行，但您的生产部署作业必须在具有生产访问权限的一个运行器上运行。您可以通过在名为 let's say 的运行器上放置一个标签prod-access并将相同的标签放置在产品部署作业上来实现此目的。这将确保作业将在具有产品访问权限的运行器上运行。这里可以使用同样的方法来确保缓存可用。
4. 使用artifacts而不是缓存。我将在下面解释这个选项，因为它确实是您应该用于此用例的选项。

我们简单解释一下Cache 和 Artifacts 之间的区别：

• 缓存通常最适合用于依赖项安装，例如npm或composer（对于 PHP 项目）。当您有一个运行npm ci或 的作业时composer install，您不希望它每次在您的管道运行时都运行，而无需更改依赖项，因为这会浪费时间。使用cache关键字来缓存依赖项，以便后续管道不必再次安装依赖项。

• 当您需要在同一管道中的作业之间共享文件或目录时，最好使用工件。例如，安装 npm 依赖项后，您可能需要node_modules在管道中的另一个作业中使用该目录。工件也会在作业结束时由运行器上传到 GitLab 服务器，而不是本地存储在运行作业的运行器上。dependencies除非使用或进行控制，否则将为所有后续作业下载所有先前的工件needs。

工件是适合您的用例的更好选择。

让我们更新您的.gitlab-ci.yml文件以artifacts代替cache：

stages:
  - build
  - deploy

generate_docu_frontend:
  image: node:12.19.0
  stage: build
  script:
    - ./generate_docs.sh # this is just a representation of whatever steps you run to generate the docs
  artifacts:
    paths:
      - frontend/node_modules
      - frontend/documentation
    expire_in: 6 hours # your GitLab instance will have a default, you can override it like this
    when: on_success # don't attempt to upload the docs if generating them failed

deploy_documentation:
  stage: deploy
  script:
    - ls # just an example showing that frontend/node_modules and frontend/documentation are present
    - deploy.sh # whatever else you need to run this job