为什么 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 页面）但它失败了，因为它没有找到文档文件夹：

$ 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 个可以访问您的生产服务器，但所有人都可以访问您的较低环境服务器。您的低环境作业可以在任何运行器上运行，但您的生产部署作业必须在具有 prod 访问权限的一个运行器上运行。您可以通过在运行器上放置一个名为让我们说prod-access 的标签并在产品部署作业上放置相同的标签来做到这一点。这将确保作业将在具有 prod 访问权限的运行器上运行。在这里可以使用相同的方法来确保缓存可用。
4. 使用artifacts 代替缓存。我将在下面解释此选项，因为它确实是您应该用于此用例的选项。

让我们简单解释一下difference between Cache and 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