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

Posted 2023-02-19

【中文标题】为啥 GitLab Ci 找不到我的缓存文件夹？

【英文标题】：Why does GitLab Ci not find my cached folder?为什么 GitLab Ci 找不到我的缓存文件夹？

【发布时间】：2021-11-16 16:57:06

【问题描述】：

我有一个在我的 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

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

【问题讨论】：

看起来您的共享缓存配置有问题...No URL provided, cache will be not uploaded to shared cache server.。作为一种快速解决方法，您可以确保两个作业使用相同的跑步者。

顺便说一句，我觉得你最好在这里使用artifacts。

【参考方案1】：

您的作业输出中的消息No URL provided, cache will be not uploaded to shared cache server. Cache will be stored only locally. 仅表示您的跑步者没有使用Amazon S3 来存储您的缓存，或者类似Minio 之类的东西。

没有 S3/Minio，缓存只存在于首先运行作业并缓存资源的运行器上。因此，下次运行作业时，如果它被另一个运行器拾取，它将没有缓存，并且您会遇到这样的错误。

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

将您的跑步者配置为使用 S3/Minio（如果您有兴趣自己托管 Minio，它有一个开源、免费使用的许可证）。 只使用一个运行器（不是一个很好的解决方案，因为通常更多的运行器意味着更快的管道，这会大大减慢速度，尽管它会解决缓存问题）。 使用tags。标签用于确保作业在特定运行器上运行。例如，假设您的 10 个运行者中有 1 个可以访问您的生产服务器，但所有人都可以访问您的较低环境服务器。您的低环境作业可以在任何运行器上运行，但您的生产部署作业必须在具有 prod 访问权限的一个运行器上运行。您可以通过在运行器上放置一个名为让我们说prod-access 的标签并在产品部署作业上放置相同的标签来做到这一点。这将确保作业将在具有 prod 访问权限的运行器上运行。在这里可以使用相同的方法来确保缓存可用。 使用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

【讨论】：

你有没有找到任何 gitlab 文档关于“只是意味着你的跑步者没有使用 Amazon S3 来存储你的缓存，或者类似 Minio 的东西。”？使用 gitlab 文档调试时遇到问题

它没有明确提到这个警告，但共享/分发的文档是here。它确实讨论了直接在跑步者上分发缓存与缓存。