GitLab CI脚本高效编写：依赖安装与并行执行优化问询

刚好之前做过类似的GitLab CI优化，给你分享下具体的实现方案，既能解决依赖重复安装的问题，又能最大化并行效率，还支持多条流水线同时跑：

1. 用模板+缓存解决依赖重复安装问题 #

每次job都重新装依赖是最耗时的环节，我们可以通过复用模板统一依赖安装逻辑，再配合GitLab CI的缓存机制让依赖在不同job甚至不同流水线之间复用，彻底省去重复安装的时间。

第一步：定义通用依赖安装模板 #

创建一个可复用的模板，把所有job都需要的依赖安装步骤放在里面，避免重复写代码：

# 定义通用依赖安装模板
.install_deps:
  before_script:
    - echo "Starting dependency installation..."
    # 替换成你的实际依赖安装命令，比如npm ci、pip install、composer install等
    - npm ci

第二步：配置全局缓存 #

把依赖目录加入缓存，设置合理的缓存key，确保不同项目、不同分支的缓存不会互相干扰：

cache:
  # 用项目ID+分支slug作为缓存key，避免跨项目/分支的缓存冲突
  key: "$CI_PROJECT_ID-$CI_COMMIT_REF_SLUG"
  # 替换成你的依赖存放路径，比如node_modules/、venv/、vendor/等
  paths:
    - node_modules/
  # 可选：设置缓存有效期，或者允许跨分支共享缓存（根据需求调整）
  # policy: pull-push

2. 配置Stage实现并行执行 #

GitLab CI默认会把同一个Stage下的所有job并行执行，只要你的Runner资源足够。我们只需要把Stage A的三个job都放在同一个stage下即可：

# 定义流水线阶段
stages:
  - stage_a
  - stage_b

# Stage A的三个并行job
job1-stageA:
  stage: stage_a
  # 复用依赖安装模板
  extends: .install_deps
  script:
    - echo "Executing Job 1 in Stage A..."
    # 这里写Job1的实际业务逻辑
  # 可选：指定Runner标签，方便分配特定资源（比如专门的Node.js Runner）
  tags:
    - node-runner

job2:
  stage: stage_a
  extends: .install_deps
  script:
    - echo "Executing Job 2 in Stage A..."
    # Job2的业务逻辑
  tags:
    - node-runner

job3:
  stage: stage_a
  extends: .install_deps
  script:
    - echo "Executing Job 3 in Stage A..."
    # Job3的业务逻辑
  tags:
    - node-runner

# Stage B的Job1（注意命名不要和Stage A的重复）
job1-stageB:
  stage: stage_b
  extends: .install_deps
  script:
    - echo "Executing Job 1 in Stage B..."
    # Stage B的Job1业务逻辑
  tags:
    - node-runner

3. 支持多条流水线同时执行的配置要点 #

要让多条流水线并行跑，核心是确保Runner资源足够，同时避免缓存冲突：

• 增加Runner资源：配置多个带有相同标签的Runner（比如上面的node-runner），或者调整单个Runner的concurrent参数，让它可以同时处理多个job请求。
• 缓存key隔离：前面设置的$CI_PROJECT_ID-$CI_COMMIT_REF_SLUG已经做到了项目和分支级别的隔离，不同流水线的缓存不会互相覆盖。
• Runner标签合理分配：如果有不同类型的job，可以给Runner设置不同的标签，比如专门的测试Runner、构建Runner，避免资源争抢。

额外优化建议 #

• 用增量安装命令：比如npm的npm ci比npm install更快，因为它严格按照package-lock.json安装，跳过了版本检查；pip可以用pip install --no-cache-dir配合缓存目录，也能提速。
• 可选：用Artifacts传递依赖：如果某些job需要确保依赖完全一致（比如构建和测试阶段），可以用artifacts把依赖目录传递给后续job，但缓存更适合跨流水线复用，Artifacts更适合同流水线内传递。
• Runner资源优化：给Runner配置足够的CPU和内存，避免因为资源不足导致job卡顿，影响并行效率。

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