GitLab CI/CD各阶段工作区不共享，如何实现全流水线共享？

GitLab流水线的每个阶段默认会在独立的Runner工作区执行，执行完成后工作区会被清理，这和Jenkins共享固定工作区的机制不同。要实现构建与发布阶段共享制品，主要有两种可靠方案：

1. 使用Artifacts传递制品（推荐） #

Artifacts是GitLab专门设计用来在流水线各阶段间传递文件的功能，构建阶段生成的制品会上传到GitLab服务器，后续阶段可以下载使用，即使不同阶段在不同Runner上执行也能生效。

示例配置：

stages:
  - build
  - deploy

# 构建阶段：生成制品并上传为artifacts
build:
  stage: build
  script:
    - # 替换为你的实际构建命令，比如 mvn package / npm run build
    - mkdir -p target
    - echo "模拟构建产物" > target/app.jar
  artifacts:
    paths:
      - target/  # 指定需要传递的制品目录/文件
    expire_in: 24h  # 可选：设置制品过期时间，避免占用存储

# 发布阶段：依赖构建阶段，自动下载artifacts
deploy:
  stage: deploy
  needs: [build]  # 明确依赖构建阶段，确保执行顺序
  script:
    - # 替换为你的实际发布命令，比如 scp target/app.jar 到服务器
    - ls -l target/  # 此处可查看构建好的制品

2. 使用Cache缓存文件 #

Cache主要用于复用依赖（如node_modules、maven仓库），也可以缓存构建产物，但仅推荐在同一Runner执行多阶段时使用——因为Cache存储在Runner本地或分布式缓存服务中，若后续阶段跑在其他Runner上，可能无法获取到缓存文件。

示例配置：

stages:
  - build
  - deploy

# 全局配置缓存路径
cache:
  paths:
    - target/

build:
  stage: build
  script:
    - # 构建命令生成target目录

deploy:
  stage: deploy
  script:
    - # 发布命令，此时target目录会从缓存加载

注意事项 #

• 不要依赖Runner工作区的持久化：GitLab Runner默认会在每次Job执行后清理工作区，强行配置持久化会破坏流水线的独立性和可靠性。
• Artifacts优先于Cache：跨Runner传递制品必须用Artifacts，Cache仅适合同Runner下的依赖复用。

内容的提问来源于stack exchange，提问作者Claudio Merli