从 Jenkins 迁移到 GitHub Actions

适用场景

希望减少 Jenkins 维护成本、使用 GitHub 原生触发和托管 Runner，或把流水线靠近代码仓库。复杂插件和自托管环境要先评估。

前置条件

• 盘点 Jenkins Job、Jenkinsfile、插件、凭据和构建节点。
• 确认仓库托管在 GitHub，且有 Actions 权限。
• 列出需要自托管 Runner 的步骤（私有网络、特殊硬件）。
• 准备并行运行和回滚窗口。

步骤

1. 盘点流水线：

# 收集 Job 和 Jenkinsfile
find . -name Jenkinsfile
# 记录插件和全局工具
java -jar jenkins-cli.jar -s <url> -auth user:token list-plugins

2. 把 Jenkinsfile 映射为 workflow：

name: CI
on:
  push:
    branches: [main]
  pull_request:
permissions:
  contents: read
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm
      - run: npm ci
      - run: npm test

3. 迁移凭据：

• Jenkins Credentials → GitHub Actions Secrets 或 OIDC。
• 能用 OIDC 的云厂商优先 OIDC，避免长期密钥。
• 自托管 Runner 配置专用标签和网络。

4. 迁移构建产物和缓存：

- uses: actions/cache@v4
  with:
    path: ~/.npm
    key: npm-${{ hashFiles('package-lock.json') }}

5. 并行运行新旧流水线，对比结果后再切换触发。

验证

• 构建、测试、制品和部署结果一致。
• 凭据、权限和审批流程正常。
• 失败日志、通知和重试可用。
• fork PR 不泄露 secrets。

回滚

• 保留 Jenkins Job 和触发配置。
• 切换 webhook/分支保护回 Jenkins。
• 保留构建产物和凭据备份。

常见坑

• Jenkins 插件专属步骤没有直接对应，需要脚本或 action 替代。
• 托管 Runner 的环境与自建节点不同；依赖预装软件会失败。
• 构建分钟数和并发限制可能影响成本。
• pull_request_target 和 fork secrets 有安全风险。
• 自托管 Runner 要隔离和清理，避免污染。

相关命令

• gh — GitHub CLI
• github-actions — 工作流配置
• jenkins — 旧流水线