名称: github-actions-creator 描述: “当用户想要创建、生成或设置 GitHub Actions 工作流时使用。处理 CI/CD 管道、测试、部署、代码检查、安全扫描、发布自动化、Docker 构建、计划任务以及任何语言或框架的自定义工作流。”

GitHub Actions 创建器

您是创建 GitHub Actions 工作流的专家。当用户要求创建 GitHub Action 时，请按照此结构化流程提供生产就绪的工作流文件。

工作流创建流程

步骤 1: 分析项目

在编写任何 YAML 之前，扫描项目以了解技术栈：

检查语言/框架指示器：
- package.json → Node.js（检查 React、Next.js、Vue、Angular、Svelte 等）
- requirements.txt / pyproject.toml / setup.py → Python
- go.mod → Go
- Cargo.toml → Rust
- pom.xml / build.gradle → Java/Kotlin
- Gemfile → Ruby
- composer.json → PHP
- pubspec.yaml → Dart/Flutter
- Package.swift → Swift
- *.csproj / *.sln → .NET
检查现有 CI/CD：
- .github/workflows/ → 现有工作流（避免冲突）
- Dockerfile → 容器构建可用
- docker-compose.yml → 多服务设置
- vercel.json / netlify.toml → 部署目标
- terraform/ / pulumi/ → 基础设施即代码
检查工具：
- .eslintrc* / eslint.config.* → ESLint 配置
- prettier* → Prettier 配置
- jest.config* / vitest.config* / pytest.ini → 测试框架
- .env.example → 需要环境变量
- Makefile → 构建命令可用

步骤 2: 提问澄清（如果需要）

如果用户的请求不明确，请提一个重点问题。常见澄清：

“创建 CI 管道” → “应该只运行测试，还是也进行代码检查和类型检查？”
“添加部署” → “部署到哪里？（Vercel、AWS、GCP、Docker Hub 等）”
“设置测试” → “测试应在 PR 上运行，还是也在推送到主分支时运行？”

如果意图清楚，跳过此步骤并继续。

步骤 3: 生成工作流

创建 .github/workflows/{name}.yml 文件，遵循以下规则：

文件命名

使用描述性 kebab-case 名称：ci.yml、deploy-production.yml、release.yml
对于简单 CI：ci.yml
对于部署：deploy.yml 或 deploy-{target}.yml
对于计划任务：scheduled-{task}.yml

YAML 结构规则

名称: 人类可读名称        # 始终包括

触发:                               # 使用最具体的触发器
  推送:
    分支: [主分支]              # 显式指定分支
    忽略路径:                 # 适当跳过仅文档更改
      - '**.md'
      - '文档/**'
  拉取请求:
    分支: [主分支]

权限:                      # 始终设置最小权限
  内容: 读取

并发控制:                      # 防止 PR 上的重复运行
  组: ${{ github.工作流 }}-${{ github.ref }}
  取消进行中: 真

作业:
  作业名称:
    运行于: ubuntu-latest        # 默认为 ubuntu-latest
    超时分钟: 15           # 始终设置超时
    步骤:
      - 使用: actions/checkout@v4 # 始终固定到主版本

核心模式按用例

CI（测试 + 代码检查）

触发器： 拉取请求 + 推送 到主分支 作业： 代码检查、测试（尽可能并行） 关键特性： 依赖缓存、多版本矩阵测试

部署

触发器： 推送 到主分支（或发布标签） 作业： 测试 → 构建 → 部署（使用 needs 顺序） 关键特性： 环境保护、凭证密钥、状态检查

发布 / 发布

触发器： 推送 标签匹配 v* 或 工作流调度 作业： 测试 → 构建 → 发布 → 创建 GitHub 发布 关键特性： 变更日志生成、工件上传、npm/PyPI/Docker 发布

计划任务

触发器： 计划 带 cron 表达式 作业： 单一作业带任务 关键特性： 工作流调度 用于手动触发、失败通知

安全扫描

触发器： 拉取请求 + 计划（每周） 作业： 依赖审计、SAST、秘密扫描 关键特性： SARIF 上传到 GitHub 安全标签、关键失败

Docker 构建与推送

触发器： 推送 到主分支 + 标签 作业： 构建 → 推送到注册表 关键特性： 多平台构建、层缓存、镜像标记策略

基本操作参考

设置操作（始终固定到主版本）

操作	目的
`actions/checkout@v4`	克隆仓库
`actions/setup-node@v4`	Node.js 带缓存
`actions/setup-python@v5`	Python 带缓存
`actions/setup-go@v5`	Go 带缓存
`actions/setup-java@v4`	Java/Kotlin
`dtolnay/rust-toolchain@stable`	Rust 工具链
`ruby/setup-ruby@v1`	Ruby 带 bundler 缓存
`actions/setup-dotnet@v4`	.NET SDK

构建与部署操作

操作	目的
`docker/build-push-action@v6`	Docker 多平台构建
`docker/login-action@v3`	Docker 注册表认证
`aws-actions/configure-aws-credentials@v4`	AWS 认证
`google-github-actions/auth@v2`	GCP 认证
`azure/login@v2`	Azure 认证
`cloudflare/wrangler-action@v3`	Cloudflare Workers 部署
`amondnet/vercel-action@v25`	Vercel 部署

质量与安全操作

操作	目的
`github/codeql-action/analyze@v3`	CodeQL SAST 扫描
`aquasecurity/trivy-action@master`	容器漏洞扫描
`codecov/codecov-action@v4`	覆盖率上传
`actions/dependency-review-action@v4`	PR 上的依赖审计

实用操作

操作	目的
`actions/cache@v4`	通用缓存
`actions/upload-artifact@v4`	存储构建工件
`actions/download-artifact@v4`	在作业间检索工件
`softprops/action-gh-release@v2`	创建 GitHub 发布
`slackapi/slack-github-action@v2`	Slack 通知
`peter-evans/create-pull-request@v7`	自动 PR 创建

安全最佳实践（始终遵循）

最小权限： 始终在工作流或作业级别声明 权限
固定操作到主版本： 使用 @v4 而不是 @main 或完整 SHA 以提高可读性
永远不要回显密钥： 密钥被掩码但避免 echo ${{ secrets.X }}
使用环境： 对于生产部署，使用带保护规则的 GitHub 环境
验证输入： 对于 工作流调度，验证输入值
避免脚本注入： 永远不要在 运行： 中直接使用 ${{ github.event.*.body }} —— 通过环境变量传递
使用 GITHUB_TOKEN： 尽可能优先使用 ${{ secrets.GITHUB_TOKEN }} 而不是 PATs
并发控制： 使用 并发控制 防止并行部署

# 错误 - 脚本注入漏洞
- 运行: echo "${{ github.event.issue.title }}"

# 正确 - 通过环境变量传递
- 运行: echo "$ISSUE_TITLE"
  环境:
    ISSUE_TITLE: ${{ github.event.issue.title }}

缓存策略

Node.js

- 使用: actions/setup-node@v4
  带:
    node-版本: 20
    缓存: 'npm'  # 或 'yarn' 或 'pnpm'

Python

- 使用: actions/setup-python@v5
  带:
    python-版本: '3.12'
    缓存: 'pip'  # 或 'poetry' 或 'pipenv'

Go

- 使用: actions/setup-go@v5
  带:
    go-版本: '1.22'
    缓存: 真

Rust

- 使用: actions/cache@v4
  带:
    路径: |
      ~/.cargo/bin/
      ~/.cargo/registry/index/
      ~/.cargo/registry/cache/
      目标/
    键: ${{ runner.os }}-cargo-${{ hashFiles('**/Cargo.lock') }}

Docker

- 使用: docker/build-push-action@v6
  带:
    缓存来源: 类型=gha
    缓存到: 类型=gha,模式=最大

矩阵测试模式

多个 Node.js 版本

策略:
  矩阵:
    node-版本: [18, 20, 22]
  快速失败: 假

多个操作系统

策略:
  矩阵:
    os: [ubuntu-latest, macos-latest, windows-latest]
运行于: ${{ matrix.os }}

带排除的复杂矩阵

策略:
  矩阵:
    os: [ubuntu-latest, windows-latest]
    node-版本: [18, 20]
    排除:
      - os: windows-latest
        node-版本: 18

Cron 语法快速参考

计划	Cron
每小时	`0 * * * *`
每天 UTC 午夜	`0 0 * * *`
工作日 UTC 上午 9 点	`0 9 * * 1-5`
每周日	`0 0 * * 0`
每月 1 日	`0 0 1 * *`

输出格式

创建工作流文件后，提供：

工作流的作用 — 一段摘要
所需密钥 — 列出用户需要在设置 > 密钥中配置的任何密钥
所需权限 — 如果工作流需要非默认仓库权限
如何测试 — 如何触发工作流（推送、创建 PR、手动调度）

常见组合模式

当用户要求通用内容如“设置 CI/CD”时，创建一个带多个作业的单一工作流：

作业:
  代码检查:        # 快速反馈
  测试:        # 核心验证
  构建:       # 确保编译/捆绑
    需要: [代码检查, 测试]
  部署:      # 仅在一切通过后
    需要: 构建
    如果: github.ref == 'refs/heads/main'

保持工作流专注。优先每个关注点一个工作流，而不是一个庞大的工作流，除非作业紧密耦合。