优化GitLab Pipeline性能：解决restore阶段耗时过长问题

核心问题分析 #

你的Pipeline存在几个直接拖慢速度的问题：

• 重复执行dotnet restore、dotnet build、dotnet publish命令，纯粹浪费时间
• 未启用缓存机制，每次Pipeline都要重新下载所有NuGet包，这是restore阶段延迟的核心原因
• 步骤拆分冗余，build和publish的流程可以合并简化

具体优化方案 #

• 移除重复命令：直接删掉所有重复的dotnet restore/build/publish行，立刻减少一半的命令执行耗时
• 合并Restore与Build：dotnet build默认会自动触发restore操作，除非有特殊NuGet源配置，不需要单独调用dotnet restore
• 配置GitLab缓存：把NuGet包缓存起来，后续Pipeline直接复用缓存，不用重复下载。Linux runner的缓存路径通常是~/.nuget/packages/
• 简化Publish流程：dotnet publish会自动完成build步骤，无需单独执行build；还能用--no-restore和--no-build参数跳过已完成的步骤，进一步提速

优化后的Pipeline示例 #

build:
  stage: build
  tags:
    - globalrunner
  cache:
    key: $CI_COMMIT_REF_SLUG
    paths:
      - ~/.nuget/packages/
  script:
    - mkdir -p src  # 加-p参数避免目录已存在时报错
    - dotnet build "example.csproj" -c Release -o /app/build 
    - echo "Build success"
  only:
    - tags

build-artifacts:
  stage: build-artifacts
  cache:
    key: $CI_COMMIT_REF_SLUG
    paths:
      - ~/.nuget/packages/
    policy: pull  # 只拉取缓存不更新，避免publish步骤干扰缓存
  artifacts:
    paths:
      - ./app/publish/
  script:
    - dotnet publish "example.csproj" -c Release -o ./app/publish --no-restore --no-build
  only:
    - tags

额外优化建议 #

• 如果是Windows runner，缓存路径要改成%USERPROFILE%\.nuget\packages\
• 可以调整缓存key为$CI_PROJECT_ID-$CI_COMMIT_REF_SLUG，保证不同项目的缓存相互隔离
• 检查runner的网络环境，若使用私有NuGet源，确保runner访问源的网络速度正常，必要时可在runner本地搭建NuGet缓存代理

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