<think>我们正在讨论
GitLab CI中的缓存
问题。用户希望了解如何清除或禁用
GitLab CI构建过程中的缓存。
根据
GitLab CI的文档，缓存（cache）和工件（artifacts）是两个不同的概念。缓存主要用于存储依赖（如node_modules, vendor等）以加速后续构建，而工件则用于存储构建结果（如编译后的二进制文件）供后续阶段
使用或下载。
用户可能遇到的情况包括：
1. 缓存过期或损坏，导致构建
失败或行为异常。
2. 希望完全禁用缓存以进行干净的构建。
3. 需要手动清除特定项目的缓存。
解决方案如下：
1. **清除项目缓存**：
在
GitLab的项目设置中，可以清除整个项目的缓存。操作路径为：
- 进入项目页面
-> Settings
->
CI/CD
-> General pipelines（或Cache）
-> 点击“Clear project caches”按钮。
注意：这个操作会清除整个项目的所有缓存，包括所有分支和标签的缓存。
2. **通过修改`.
gitlab-ci.yml`文件禁用缓存**：
如果不想在某个作业中
使用缓存，可以在作业中设置`cache: {}`来禁用该作业的缓存。例如：
```yaml
job_without_cache:
script: echo "This job does not use cache."
cache: []
```
如果希望全局禁用缓存，可以在全局设置`cache: {}`，但注意这样会覆盖每个作业的缓存设置。不过，更常见的做法是在不需要缓存的作业中单独禁用。
3. **通过修改缓存键（key）来刷新缓存**：
如果只是想强制更新缓存，可以修改缓存配置中的`key`。例如，在`.
gitlab-ci.yml`中，可以设置一个版本号作为key的一部分，当需要更新缓存时，更改版本号即可：
```yaml
cache:
key: "v1.0
-$
CI_COMMIT_REF_SLUG" # 修改v1.0为v1.1即可刷新缓存
paths:
- node_modules/
```
4. **
使用`
gitlab-runner`
命令行清除缓存**（需要访问
Runner服务器）：
如果
Runner是
shell执行器，并且你有权访问服务器，可以手动删除缓存目录。默认情况下，缓存存储在`
gitlab-runner`用户的家目录下，具体路径为：`/home/
gitlab-runner/cache/<项目ID>/<项目路径>`。
可以运行以下
命令清除（请替换为实际路径）：
```bash
rm
-rf /home/
gitlab-runner/cache/<项目ID>/*
```
或者，如果
Runner配置中指定了缓存目录（在`config.toml`中设置`cache_dir`），则删除该目录下的对应项目缓存。
5. **
使用`needs: []`避免
使用缓存**：
如果作业之间不需要传递缓存，可以
使用`needs: []`来避免依赖之前作业的缓存。但这种方法并不是直接清除缓存，而是跳过缓存的下载。
6. **在作业中
使用`
--no
-cache`参数**（如果适用）：
某些
命令（如`
docker build`）有`
--no
-cache`选项，可以在构建镜像时不
使用缓存。但这不是
GitLab CI缓存的直接控制，而是针对具体
命令。
7. **通过API清除缓存**（
GitLab 13.4及以上版本）：
可以
使用GitLab API来清除项目的缓存。API
调用如下：
```bash
curl
--request POST
--header "PRIVATE
-TOKEN: <your_access_token>" "https://
gitlab.example.com/api/v4/projects/<project_id>/cache"
```
注意：需要替换`<your_access_token>`和`<project_id>`，以及
GitLab实例的URL。
重要提示：清除缓存会导致下一次构建时间变长，因为需要重新下载所有依赖。
如果用户遇到缓存导致的
问题，建议先尝试清除项目缓存（方法1），然后观察构建是否恢复正常。如果
问题仍然存在，可能需要检查缓存策略（如`cache:key`和`cache:policy`）是否合理。
下面是一个示例`.
gitlab-ci.yml`文件，展示了如何配置缓存以及如何禁用特定作业的缓存：
```yaml
# 全局缓存设置（所有作业默认
使用）
cache:
key: ${
CI_COMMIT_REF_SLUG}
paths:
- node_modules/
- vendor/
stages:
- build
- test
build_job:
stage:
build
script:
- npm install
- bundle install
test_job:
stage: test
script: npm test
# 禁用此作业的缓存
cache: []
# 另一个作业，
使用不同的缓存策略
deploy_job:
stage:
deploy
script: ./
deploy.sh
cache:
key: ${
CI_COMMIT_REF_SLUG}
-deploy
paths:
- dist/
```
在这个例子中，`test_job`禁用了缓存，而其他作业则
使用缓存。
最后，关于缓存策略的选择：
- `pull`：作业开始时下载缓存，结束时不上传（默认策略）
- `push`：作业结束时上传缓存，但下载时如果不存在则不下载
- `pull
-push`：作业开始时下载，结束时上传（默认行为，除非全局设置覆盖）
- `cache:policy: pull`：只下载不上传（适用于后续作业不需要更新缓存的场景）
如果需要强制重新下载依赖而不
使用任何缓存，可以在作业中设置`cache: []`，或者清除整个项目的缓存。
如果用户的
问题是由于缓存了错误的依赖版本导致的，可以尝试调整缓存key，例如将依赖文件（如`package
-lock.json`）的哈希值作为key的一部分，这样当依赖变化时自动更新缓存。
示例：
```yaml
cache:
key:
files:
- package
-lock.json
paths:
- node_modules/
```
这样，当`package
-lock.json`发生变化时，缓存key就会改变，从而创建新的缓存。
希望这些方法能帮助用户
解决问题。
相关
问题：
1. 如何查看
GitLab CI缓存的内容？
2. 如何限制
GitLab CI缓存的大小？
3. 如何配置
GitLab Runner的缓存存储位置？
4. 缓存和工件（artifacts）有什么区别？</think>###
GitLab CI 缓存管理指南
缓存是
GitLab CI/CD 的核心功能之一，用于加速构建过程。以下是清除或禁用缓存的完整
解决方案：
---
#### 一、清除缓存的方法
1. **通过 UI 手动清除**
- 进入项目页面 → **Settings →
CI/CD**
- 展开 **General pipelines** 区域
- 点击 **Clear project caches** 按钮
- 确认后立即生效[^1]
```mermaid
graph LR
A[Project Settings]
--> B[
CI/CD]
B
--> C[General pipelines]
C
--> D[Clear project caches]
```
2. **通过 API 清除**
使用 `curl`
调用 GitLab API：
```bash
curl
--request POST
--header "PRIVATE
-TOKEN: <your_access_token>" \
"https://
gitlab.example.com/api/v4/projects/<project_id>/cache"
```
- 获取 `<project_id>`：项目首页 URL 中的数字 ID
- 生成 `<your_access_token>`：**User Settings → Access Tokens**
3. **修改缓存键强制刷新**
在 `.
gitlab-ci.yml` 中修改 `cache:key` 触发新缓存：
```yaml
cache:
key: "new
-key
-v2" # 修改此值即可刷新缓存
paths:
- node_modules/
```
---
#### 二、禁用缓存的策略
1. **全局禁用缓存**
在 `.
gitlab-ci.yml` 中添加空缓存声明：
```yaml
cache: {}
```
2. **按作业禁用缓存**
在特定作业中覆盖全局设置：
```yaml
job_without_cache:
script: echo "Running without cache"
cache: [] # 空数组禁用缓存
```
3. **
使用 `dependen
cies: []` 隔离缓存**
阻止作业继承缓存：
```yaml
build:
stage:
build
cache:
paths: [
build/]
test:
stage: test
dependen
cies: [] # 不接收任何缓存
script: ./run
-tests
```
---
#### 三、缓存行为控制技巧
1. **缓存策略选择**
```yaml
cache:
policy: pull # 仅下载缓存（不上传）
# policy: push # 仅上传缓存（不下载）
# policy: pull
-push # 默认行为
```
2. **缓存过期设置**
```yaml
cache:
key: binaries
paths: [bin/]
untracked: true # 缓存未跟踪文件
when: on_success # 仅在作业成功时缓存
```
3. **排除特定目录**
```yaml
cache:
paths:
- vendor/
exclude:
- vendor/ruby
-3.0/ # 排除此目录
```
---
#### 四、常见
问题排查
| 现象 |
解决方案 |
|
------|
----------|
| 缓存未更新 | 检查 `cache:key` 是否唯一，或手动清除缓存 |
| 缓存冲突 |
使用 `cache:key:files` 基于文件哈希生成动态 key<br>例：`key: "$
CI_COMMIT_REF_SLUG
-$
CI_JOB_
NAME"` |
| 缓存过大 | 设置 `artifacts:expire_in` 控制保留时间 |
| 缓存污染 |
使用 `before_script` 清理旧文件：<br>`rm
-rf node_modules/.cache/` |
---
#### 五、缓存与 Artifacts 的区别
| 特性 | **缓存 (Cache)** | **工件 (Artifacts)** |
|
------|
------------------|
----------------------|
| 用途 | 加速后续构建 | 传递构建结果 |
| 存储位置 |
Runner 本地 / S3 |
GitLab 服务器 |
| 生命周期 | 可能被清理 | 永久或按策略保留 |
| 下载方式 | 自动 | 需手动或通过 API 下载 |
> 最佳实践：**小文件用缓存，构建产物用 artifacts**[^2]
在使用GitLabCI进行Docker镜像构建时遇到权限问题，即使在yml文件中运行whoami显示为root用户，直接运行docker build仍然失败。通过使用sudo命令解决了这一问题，使构建和推送流程得以顺利进行。
扫一扫
194
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
