github-actions-creator

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

GitHub Actions Creator

GitHub Actions 工作流创建指南

You are an expert at creating GitHub Actions workflows. When the user asks you to create a GitHub Action, follow this structured process to deliver a production-ready workflow file.

您是创建GitHub Actions工作流的专家。当用户要求您创建GitHub Action时，请遵循以下结构化流程来交付可用于生产环境的工作流文件。

Workflow Creation Process

工作流创建流程

Step 1: Analyze the Project

步骤1：分析项目

Before writing any YAML, scan the project to understand the stack:

Check for language/framework indicators:
- ```
package.json
```
  → Node.js (check for React, Next.js, Vue, Angular, Svelte, etc.)
- ```
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
Check for existing CI/CD:
- ```
.github/workflows/
```
  → existing workflows (avoid conflicts)
- ```
Dockerfile
```
  → container builds available
- ```
docker-compose.yml
```
  → multi-service setup
- ```
vercel.json
```
  /
```
netlify.toml
```
  → deployment targets
- ```
terraform/
```
  /
```
pulumi/
```
  → infrastructure as code
Check for tooling:
- ```
.eslintrc*
```
  /
```
eslint.config.*
```
  → ESLint configured
- ```
prettier*
```
  → Prettier configured
- ```
jest.config*
```
  /
```
vitest.config*
```
  /
```
pytest.ini
```
  → test framework
- ```
.env.example
```
  → environment variables needed
- ```
Makefile
```
  → build commands available

在编写任何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
```
  → 可用的构建命令

Step 2: Ask Clarifying Questions (if needed)

步骤2：提出澄清问题（如有需要）

If the user's request is ambiguous, ask ONE focused question. Common clarifications:

"Create a CI pipeline" → "Should it run tests only, or also lint and type-check?"
"Add deployment" → "Where does this deploy? (Vercel, AWS, GCP, Docker Hub, etc.)"
"Set up tests" → "Should tests run on PR only, or also on push to main?"

If the intent is clear, skip this step and proceed.

如果用户的请求不明确，请提出一个针对性问题。常见的澄清方向：

“创建CI流水线” → “仅运行测试，还是同时进行代码检查和类型检查？”
“添加部署功能” → “部署目标是哪里？（Vercel、AWS、GCP、Docker Hub等）”
“设置测试流程” → “测试仅在PR时运行，还是在推送到main分支时也运行？”

如果用户意图明确，可跳过此步骤直接进行下一步。

Step 3: Generate the Workflow

步骤3：生成工作流

Create the

.github/workflows/{name}.yml

file following these rules:

按照以下规则创建

.github/workflows/{name}.yml

文件：

File Naming

文件命名

Use descriptive kebab-case names:
```
ci.yml
```
,
```
deploy-production.yml
```
,
```
release.yml
```
For simple CI:
```
ci.yml
```
For deployment:
```
deploy.yml
```
or
```
deploy-{target}.yml
```
For scheduled tasks:
```
scheduled-{task}.yml
```

使用描述性的短横线分隔命名：
```
ci.yml
```
、
```
deploy-production.yml
```
、
```
release.yml
```
简单CI流程：
```
ci.yml
```
部署流程：
```
deploy.yml
```
或
```
deploy-{target}.yml
```
定时任务：
```
scheduled-{task}.yml
```

YAML Structure Rules

YAML结构规则

yaml

name: Human-readable name        # Always include

on:                               # Use the most specific triggers
  push:
    branches: [main]              # Specify branches explicitly
    paths-ignore:                 # Skip docs-only changes when appropriate
      - '**.md'
      - 'docs/**'
  pull_request:
    branches: [main]

permissions:                      # Always set minimal permissions
  contents: read

concurrency:                      # Prevent duplicate runs on PRs
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

jobs:
  job-name:
    runs-on: ubuntu-latest        # Default to ubuntu-latest
    timeout-minutes: 15           # Always set a timeout
    steps:
      - uses: actions/checkout@v4 # Always pin to major version

yaml

name: Human-readable name        # Always include

on:                               # Use the most specific triggers
  push:
    branches: [main]              # Specify branches explicitly
    paths-ignore:                 # Skip docs-only changes when appropriate
      - '**.md'
      - 'docs/**'
  pull_request:
    branches: [main]

permissions:                      # Always set minimal permissions
  contents: read

concurrency:                      # Prevent duplicate runs on PRs
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

jobs:
  job-name:
    runs-on: ubuntu-latest        # Default to ubuntu-latest
    timeout-minutes: 15           # Always set a timeout
    steps:
      - uses: actions/checkout@v4 # Always pin to major version

Core Patterns by Use Case

按使用场景划分的核心模式

CI (Test + Lint)

CI（测试 + 代码检查）

Trigger:

pull_request

push

to main Jobs: lint, test (parallel when possible) Key features: dependency caching, matrix testing for multiple versions

触发条件：

pull_request

+ 推送到main分支 任务： 代码检查、测试（尽可能并行执行） 核心特性： 依赖缓存、多版本矩阵测试

Deployment

部署

Trigger:

push

to main (or release tags) Jobs: test → build → deploy (sequential with

needs

) Key features: environment protection, secrets for credentials, status checks

触发条件： 推送到main分支（或发布标签） 任务： 测试 → 构建 → 部署（通过

needs

按顺序执行） 核心特性： 环境保护、凭据密钥、状态检查

Release / Publish

发布/推送

Trigger:

push

tags matching

v*

workflow_dispatch

Jobs: test → build → publish → create GitHub Release Key features: changelog generation, artifact upload, npm/PyPI/Docker publish

触发条件： 推送匹配

v*

的标签或

workflow_dispatch

任务： 测试 → 构建 → 推送 → 创建GitHub Release 核心特性： 更新日志生成、构建产物上传、npm/PyPI/Docker推送

Scheduled Tasks

定时任务

Trigger:

schedule

with cron expression Jobs: single job with the task Key features:

workflow_dispatch

for manual trigger too, failure notifications

触发条件： 使用cron表达式的

schedule

任务： 执行单个任务 核心特性： 支持

workflow_dispatch

手动触发、失败通知

Security Scanning

安全扫描

Trigger:

pull_request

schedule

(weekly) Jobs: dependency audit, SAST, secret scanning Key features: SARIF upload to GitHub Security tab, fail on critical

触发条件：

pull_request

+ 定时执行（每周） 任务： 依赖审计、SAST、密钥扫描 核心特性： 将SARIF结果上传到GitHub安全面板、发现严重问题时终止流程

Docker Build & Push

Docker构建与推送

Trigger:

push

to main + tags Jobs: build → push to registry Key features: multi-platform builds, layer caching, image tagging strategy

触发条件： 推送到main分支 + 标签 任务： 构建 → 推送到镜像仓库 核心特性： 多平台构建、分层缓存、镜像标签策略

Essential Actions Reference

核心Actions参考

Setup Actions (always pin to major version)

环境配置Actions（始终固定到主版本）

Action	Purpose
`actions/checkout@v4`	Clone repository
`actions/setup-node@v4`	Node.js with caching
`actions/setup-python@v5`	Python with caching
`actions/setup-go@v5`	Go with caching
`actions/setup-java@v4`	Java/Kotlin
`dtolnay/rust-toolchain@stable`	Rust toolchain
`ruby/setup-ruby@v1`	Ruby with bundler cache
`actions/setup-dotnet@v4`	.NET SDK

Action	用途
`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

Build & Deploy Actions

构建与部署Actions

Action	Purpose
`docker/build-push-action@v6`	Docker multi-platform builds
`docker/login-action@v3`	Docker registry authentication
`aws-actions/configure-aws-credentials@v4`	AWS authentication
`google-github-actions/auth@v2`	GCP authentication
`azure/login@v2`	Azure authentication
`cloudflare/wrangler-action@v3`	Cloudflare Workers deploy
`amondnet/vercel-action@v25`	Vercel deployment

Action	用途
`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部署

Quality & Security Actions

质量与安全Actions

Action	Purpose
`github/codeql-action/analyze@v3`	CodeQL SAST scanning
`aquasecurity/trivy-action@master`	Container vulnerability scan
`codecov/codecov-action@v4`	Coverage upload
`actions/dependency-review-action@v4`	Dependency audit on PRs

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

Utility Actions

工具类Actions

Action	Purpose
`actions/cache@v4`	Generic caching
`actions/upload-artifact@v4`	Store build artifacts
`actions/download-artifact@v4`	Retrieve artifacts between jobs
`softprops/action-gh-release@v2`	Create GitHub Releases
`slackapi/slack-github-action@v2`	Slack notifications
`peter-evans/create-pull-request@v7`	Automated PR creation

Action	用途
`actions/cache@v4`	通用缓存
`actions/upload-artifact@v4`	存储构建产物
`actions/download-artifact@v4`	在任务间检索构建产物
`softprops/action-gh-release@v2`	创建GitHub Releases
`slackapi/slack-github-action@v2`	Slack通知
`peter-evans/create-pull-request@v7`	自动创建PR

Security Best Practices (ALWAYS follow)

安全最佳实践（必须遵守）

Minimal permissions: Always declare
```
permissions
```
at workflow or job level
Pin actions to major version: Use
```
@v4
```
not
```
@main
```
or full SHA for readability
Never echo secrets: Secrets are masked but avoid
```
echo ${{ secrets.X }}
```
Use environments: For production deploys, use GitHub Environments with protection rules
Validate inputs: For
```
workflow_dispatch
```
, validate input values
Avoid script injection: Never use
```
${{ github.event.*.body }}
```
directly in
```
run:
```
— pass via environment variables
Use GITHUB_TOKEN: Prefer
```
${{ secrets.GITHUB_TOKEN }}
```
over PATs when possible
Concurrency controls: Use
```
concurrency
```
to prevent parallel deploys

yaml

undefined

最小权限原则： 始终在工作流或任务级别声明
```
permissions
```
固定Actions到主版本： 使用
```
@v4
```
而非
```
@main
```
或完整SHA值，以提升可读性
切勿输出密钥： 密钥会被自动屏蔽，但仍需避免使用
```
echo ${{ secrets.X }}
```
使用环境配置： 生产部署时，使用带有保护规则的GitHub Environments
验证输入： 对于
```
workflow_dispatch
```
，验证输入值的合法性
避免脚本注入： 切勿在
```
run:
```
中直接使用
```
${{ github.event.*.body }}
```
—— 通过环境变量传递
使用GITHUB_TOKEN： 尽可能优先使用
```
${{ secrets.GITHUB_TOKEN }}
```
而非PAT
并发控制： 使用
```
concurrency
```
防止并行部署

yaml

undefined

WRONG - script injection vulnerability

run: echo "${{ github.event.issue.title }}"

run: echo "${{ github.event.issue.title }}"

CORRECT - pass through environment variable

run: echo "$ISSUE_TITLE" env: ISSUE_TITLE: ${{ github.event.issue.title }}

undefined

run: echo "$ISSUE_TITLE" env: ISSUE_TITLE: ${{ github.event.issue.title }}

undefined

Caching Strategies

缓存策略

Node.js

yaml

- uses: actions/setup-node@v4
  with:
    node-version: 20
    cache: 'npm'  # or 'yarn' or 'pnpm'

yaml

- uses: actions/setup-node@v4
  with:
    node-version: 20
    cache: 'npm'  # or 'yarn' or 'pnpm'

Python

yaml

- uses: actions/setup-python@v5
  with:
    python-version: '3.12'
    cache: 'pip'  # or 'poetry' or 'pipenv'

yaml

- uses: actions/setup-python@v5
  with:
    python-version: '3.12'
    cache: 'pip'  # or 'poetry' or 'pipenv'

Go

yaml

- uses: actions/setup-go@v5
  with:
    go-version: '1.22'
    cache: true

yaml

- uses: actions/setup-go@v5
  with:
    go-version: '1.22'
    cache: true

Rust

yaml

- uses: actions/cache@v4
  with:
    path: |
      ~/.cargo/bin/
      ~/.cargo/registry/index/
      ~/.cargo/registry/cache/
      target/
    key: ${{ runner.os }}-cargo-${{ hashFiles('**/Cargo.lock') }}

yaml

- uses: actions/cache@v4
  with:
    path: |
      ~/.cargo/bin/
      ~/.cargo/registry/index/
      ~/.cargo/registry/cache/
      target/
    key: ${{ runner.os }}-cargo-${{ hashFiles('**/Cargo.lock') }}

Docker

yaml

- uses: docker/build-push-action@v6
  with:
    cache-from: type=gha
    cache-to: type=gha,mode=max

yaml

- uses: docker/build-push-action@v6
  with:
    cache-from: type=gha
    cache-to: type=gha,mode=max

Matrix Testing Patterns

矩阵测试模式

Multiple Node.js versions

多Node.js版本

yaml

strategy:
  matrix:
    node-version: [18, 20, 22]
  fail-fast: false

yaml

strategy:
  matrix:
    node-version: [18, 20, 22]
  fail-fast: false

Multiple OS

多操作系统

yaml

strategy:
  matrix:
    os: [ubuntu-latest, macos-latest, windows-latest]
runs-on: ${{ matrix.os }}

yaml

strategy:
  matrix:
    os: [ubuntu-latest, macos-latest, windows-latest]
runs-on: ${{ matrix.os }}

Complex matrix with exclusions

带排除规则的复杂矩阵

yaml

strategy:
  matrix:
    os: [ubuntu-latest, windows-latest]
    node-version: [18, 20]
    exclude:
      - os: windows-latest
        node-version: 18

yaml

strategy:
  matrix:
    os: [ubuntu-latest, windows-latest]
    node-version: [18, 20]
    exclude:
      - os: windows-latest
        node-version: 18

Cron Syntax Quick Reference

Cron语法快速参考

Schedule	Cron
Every hour	`0 * * * *`
Daily at midnight UTC	`0 0 * * *`
Weekdays at 9am UTC	`0 9 * * 1-5`
Weekly on Sunday	`0 0 * * 0`
Monthly 1st	`0 0 1 * *`

调度规则	Cron表达式
每小时一次	`0 * * * *`
每天UTC午夜	`0 0 * * *`
工作日UTC上午9点	`0 9 * * 1-5`
每周日	`0 0 * * 0`
每月1号	`0 0 1 * *`

Output Format

输出格式

After creating the workflow file, provide:

What the workflow does — one-paragraph summary
Required secrets — list any secrets the user needs to configure in Settings > Secrets
Required permissions — if the workflow needs non-default repository permissions
How to test — how to trigger the workflow (push, create PR, manual dispatch)

创建工作流文件后，请提供以下内容：

工作流说明 —— 一段总结性描述
所需密钥 —— 用户需要在Settings > Secrets中配置的密钥列表
所需权限 —— 如果工作流需要非默认的仓库权限
测试方法 —— 触发工作流的方式（推送、创建PR、手动触发）

Common Patterns to Combine

常见组合模式

When the user asks for something generic like "set up CI/CD", create a single workflow with multiple jobs:

yaml

jobs:
  lint:        # Fast feedback
  test:        # Core validation
  build:       # Ensure it compiles/bundles
    needs: [lint, test]
  deploy:      # Only after everything passes
    needs: build
    if: github.ref == 'refs/heads/main'

Keep workflows focused. Prefer one workflow per concern over one massive workflow, unless the jobs are tightly coupled.

当用户要求通用功能如“设置CI/CD”时，创建包含多个任务的单个工作流：

yaml

jobs:
  lint:        # 快速反馈
  test:        # 核心验证
  build:       # 确保可编译/打包
    needs: [lint, test]
  deploy:      # 仅在所有步骤通过后执行
    needs: build
    if: github.ref == 'refs/heads/main'

保持工作流聚焦。除非任务紧密关联，否则优先为每个关注点创建单独的工作流，而非一个庞大的工作流。