CI/CD Pipeline Generator
Overview
Generate production-ready CI/CD pipeline configuration files for various platforms (GitHub Actions, GitLab CI, CircleCI, Jenkins). This skill provides templates and guidance for setting up automated workflows that handle linting, testing, building, and deployment for modern web applications, particularly Node.js/Next.js projects.
Core Capabilities
1. Platform Selection
Choose the appropriate CI/CD platform based on project requirements:
- - GitHub Actions: Best for GitHub-hosted projects with native integration
- GitLab CI/CD: Ideal for GitLab repositories with complex pipeline needs
- CircleCI: Optimized for Docker workflows and fast build times
- Jenkins: Suitable for self-hosted, highly customizable environments
Refer to references/platform-comparison.md for detailed platform comparisons, pros/cons, and use case recommendations.
2. Pipeline Configuration Generation
Generate pipeline configs following these principles:
Pipeline Stages
Structure pipelines with these standard stages:
- 1. Install Dependencies
- Checkout code from repository
- Setup runtime environment (Node.js version)
- Restore cached dependencies
- Install dependencies with
npm ci
- Cache dependencies for future runs
- 2. Lint
- Run ESLint for code quality
- Run TypeScript type checking
- Fail fast on linting errors
- 3. Test
- Execute unit tests
- Execute integration tests
- Generate code coverage reports
- Upload coverage to reporting services (Codecov, Coveralls)
- 4. Build
- Create production build
- Verify build succeeds
- Store build artifacts
- 5. Deploy
- Deploy to staging (develop branch)
- Deploy to production (main branch)
- Run post-deployment smoke tests
Caching Strategy
Implement effective caching to speed up builds:
CODEBLOCK0
Environment Variables
Configure necessary environment variables:
- -
NODE_ENV: Set to production for builds - Platform-specific tokens: Store as secrets
- Build-time variables: Pass to build process
3. Template Usage
Use provided templates from assets/ directory:
GitHub Actions Template (assets/github-actions-nodejs.yml):
- - Multi-job workflow with lint, test, build, deploy
- Matrix builds for multiple Node.js versions (optional)
- Vercel deployment integration
- Artifact uploading
- Code coverage reporting
GitLab CI Template (assets/gitlab-ci-nodejs.yml):
- - Multi-stage pipeline
- Dependency caching
- Manual production deployment
- Automatic staging deployment
- Coverage reporting
To use a template:
- 1. Copy the appropriate template file
- Place in the correct location:
- GitHub Actions:
.github/workflows/ci.yml
- GitLab CI:
.gitlab-ci.yml
- 3. Customize deployment targets, environment variables, and branch names
- Add required secrets to platform settings
4. Deployment Configuration
Vercel Deployment
For GitHub Actions:
CODEBLOCK1
Required Secrets:
- -
VERCEL_TOKEN: Get from Vercel account settings - INLINECODE10 : From Vercel project settings
- INLINECODE11 : From Vercel project settings
Netlify Deployment
CODEBLOCK2
AWS S3 + CloudFront
CODEBLOCK3
5. Testing Integration
Configure test execution with proper reporting:
Jest Configuration:
CODEBLOCK4
Fail Fast Strategy:
CODEBLOCK5
6. Branch-Based Workflows
Implement different behaviors per branch:
Feature Branches / PRs:
- - Run lint + test only
- No deployment
- Add PR comments with test results
Develop Branch:
- - Run lint + test + build
- Deploy to staging environment
- Automatic deployment
Main Branch:
- - Run lint + test + build
- Deploy to production
- Manual approval (optional)
- Create release tags
Example:
CODEBLOCK6
Workflow Decision Tree
Follow this decision tree to generate the appropriate pipeline:
- 1. Which platform?
- GitHub → Use
assets/github-actions-nodejs.yml
- GitLab → Use
assets/gitlab-ci-nodejs.yml
- CircleCI/Jenkins → Adapt GitHub Actions template
- Unsure → Consult INLINECODE14
- 2. What stages are needed?
- Always include: Lint, Test, Build
- Optional: Security scanning, E2E tests, performance tests
- Add deployment stage if deploying from CI
- 3. Which deployment platform?
- Vercel → Use Vercel deployment examples
- Netlify → Use Netlify CLI approach
- AWS → Use AWS Actions/CLI
- Custom → Implement custom deployment script
- 4. What triggers?
- On push to main/develop
- On pull request
- On tag creation
- Manual workflow dispatch
- 5. What environment variables needed?
- Platform tokens (Vercel, Netlify, AWS)
- API keys for external services
- Build-time environment variables
- Feature flags
Best Practices
Security
- - Store all secrets in platform secret management (never in code)
- Use least-privilege tokens (read-only when possible)
- Rotate secrets regularly
- Audit secret access permissions
- Never log secrets (use
*** masking)
Performance
- - Cache dependencies aggressively
- Parallelize independent jobs
- Use matrix builds for multi-version testing
- Fail fast: Run quick checks before slow ones
- Optimize Docker layer caching
Reliability
- - Pin exact Node.js versions (
18.x not just 18) - Commit lockfiles (
package-lock.json) - Add retry logic for flaky external services
- Set reasonable timeouts (10-15 minutes max)
- Use
continue-on-error for non-critical steps
Maintainability
- - Add comments explaining complex logic
- Use reusable workflows/templates
- Keep configs DRY (Don't Repeat Yourself)
- Version control all pipeline changes
- Document required secrets in README
Common Patterns
Multi-Environment Deployment
CODEBLOCK7
Matrix Testing
CODEBLOCK8
Conditional Steps
CODEBLOCK9
Artifact Management
CODEBLOCK10
Troubleshooting
Pipeline Failures
- 1. Check action/job logs for error messages
- Verify environment variables and secrets are set
- Test commands locally before adding to pipeline
- Check for platform-specific issues in documentation
Slow Builds
- 1. Verify cache is working (check cache hit/miss logs)
- Parallelize independent jobs
- Use faster runners if available
- Optimize dependency installation
Deployment Failures
- 1. Verify deployment tokens are valid
- Check platform status pages
- Review deployment logs
- Test deployment commands locally
Resources
Templates (assets/)
- -
github-actions-nodejs.yml: Complete GitHub Actions workflow - INLINECODE22 : Complete GitLab CI pipeline
Reference Documentation (references/)
- -
platform-comparison.md: Detailed comparison of CI/CD platforms, deployment targets, best practices, and common patterns
Example Usage
User Request: "Create a GitHub Actions workflow that runs tests and deploys to Vercel"
Steps:
- 1. Copy
assets/github-actions-nodejs.yml template - Create
.github/workflows/ directory if it doesn't exist - Save as INLINECODE27
- Update deployment section with Vercel credentials
- Add secrets to GitHub repository settings:
-
VERCEL_TOKEN
-
VERCEL_ORG_ID
-
VERCEL_PROJECT_ID
- 6. Commit and push to trigger workflow
User Request: "Set up GitLab CI with staging and production environments"
Steps:
- 1. Copy
assets/gitlab-ci-nodejs.yml template - Save as
.gitlab-ci.yml in repository root - Configure GitLab CI/CD variables:
-
VERCEL_TOKEN
- Other deployment credentials
- 4. Review manual approval settings for production
- Commit to trigger pipeline
Advanced Configuration
Monorepo Support
CODEBLOCK11
Scheduled Runs
CODEBLOCK12
External Service Integration
CODEBLOCK13
Security Scanning
CODEBLOCK14
CI/CD 管道生成器
概述
为各种平台(GitHub Actions、GitLab CI、CircleCI、Jenkins)生成可用于生产环境的CI/CD管道配置文件。此技能提供模板和指导,用于设置自动化工作流,处理现代Web应用程序(特别是Node.js/Next.js项目)的代码检查、测试、构建和部署。
核心能力
1. 平台选择
根据项目需求选择合适的CI/CD平台:
- - GitHub Actions:最适合托管在GitHub上的项目,具有原生集成
- GitLab CI/CD:适用于具有复杂管道需求的GitLab仓库
- CircleCI:针对Docker工作流和快速构建时间进行了优化
- Jenkins:适用于自托管、高度可定制的环境
有关详细的平台比较、优缺点和用例建议,请参阅 references/platform-comparison.md。
2. 管道配置生成
按照以下原则生成管道配置:
管道阶段
使用以下标准阶段构建管道:
- 1. 安装依赖
- 从仓库检出代码
- 设置运行时环境(Node.js版本)
- 恢复缓存的依赖
- 使用 npm ci 安装依赖
- 缓存依赖以供将来运行
- 2. 代码检查
- 运行ESLint进行代码质量检查
- 运行TypeScript类型检查
- 在代码检查错误时快速失败
- 3. 测试
- 执行单元测试
- 执行集成测试
- 生成代码覆盖率报告
- 将覆盖率上传到报告服务(Codecov、Coveralls)
- 4. 构建
- 创建生产构建
- 验证构建成功
- 存储构建产物
- 5. 部署
- 部署到预发布环境(develop分支)
- 部署到生产环境(main分支)
- 运行部署后冒烟测试
缓存策略
实施有效的缓存以加速构建:
yaml
基于package-lock.json缓存node_modules
cache:
key: ${{ hashFiles(package-lock.json) }}
paths:
- node_modules/
- .npm/
环境变量
配置必要的环境变量:
- - NODE_ENV:构建时设置为 production
- 平台特定令牌:存储为密钥
- 构建时变量:传递给构建过程
3. 模板使用
使用 assets/ 目录中提供的模板:
GitHub Actions模板(assets/github-actions-nodejs.yml):
- - 包含代码检查、测试、构建、部署的多作业工作流
- 多个Node.js版本的矩阵构建(可选)
- Vercel部署集成
- 产物上传
- 代码覆盖率报告
GitLab CI模板(assets/gitlab-ci-nodejs.yml):
- - 多阶段管道
- 依赖缓存
- 手动生产部署
- 自动预发布部署
- 覆盖率报告
使用模板:
- 1. 复制相应的模板文件
- 放置在正确的位置:
- GitHub Actions:.github/workflows/ci.yml
- GitLab CI:.gitlab-ci.yml
- 3. 自定义部署目标、环境变量和分支名称
- 在平台设置中添加所需的密钥
4. 部署配置
Vercel部署
对于GitHub Actions:
yaml
- - uses: amondnet/vercel-action@v25
with:
vercel-token: ${{ secrets.VERCEL_TOKEN }}
vercel-org-id: ${{ secrets.VERCEL
ORGID }}
vercel-project-id: ${{ secrets.VERCEL
PROJECTID }}
vercel-args: --prod
所需密钥:
- - VERCELTOKEN:从Vercel账户设置获取
- VERCELORGID:从Vercel项目设置获取
- VERCELPROJECT_ID:从Vercel项目设置获取
Netlify部署
yaml
npm install -g netlify-cli
netlify deploy --prod --dir=.next
env:
NETLIFY
AUTHTOKEN: ${{ secrets.NETLIFY
AUTHTOKEN }}
NETLIFY
SITEID: ${{ secrets.NETLIFY
SITEID }}
AWS S3 + CloudFront
yaml
- - uses: aws-actions/configure-aws-credentials@v4
with:
aws-access-key-id: ${{ secrets.AWS
ACCESSKEY_ID }}
aws-secret-access-key: ${{ secrets.AWS
SECRETACCESS_KEY }}
aws-region: us-east-1
aws s3 sync .next/static s3://${{ secrets.S3_BUCKET }}/static
aws cloudfront create-invalidation --distribution-id ${{ secrets.CF
DISTID }} --paths /*
5. 测试集成
配置带有适当报告的测试执行:
Jest配置:
yaml
- - name: Run tests with coverage
run: npm test -- --coverage --coverageReporters=text --coverageReporters=lcov
uses: codecov/codecov-action@v4
with:
files: ./coverage/lcov.info
flags: unittests
快速失败策略:
yaml
先运行快速测试
jobs:
lint: # 约30秒内失败
test: # 约2分钟内失败
build: # 约5分钟内失败
needs: [lint, test]
deploy:
needs: [build]
6. 基于分支的工作流
为每个分支实现不同的行为:
功能分支/PR:
- - 仅运行代码检查+测试
- 不部署
- 在PR评论中添加测试结果
Develop分支:
- - 运行代码检查+测试+构建
- 部署到预发布环境
- 自动部署
Main分支:
- - 运行代码检查+测试+构建
- 部署到生产环境
- 手动审批(可选)
- 创建发布标签
示例:
yaml
deploy_staging:
if: github.ref == refs/heads/develop
# 部署到预发布环境
deploy_production:
if: github.ref == refs/heads/main
environment: production # 需要手动审批
# 部署到生产环境
工作流决策树
按照以下决策树生成适当的管道:
- 1. 哪个平台?
- GitHub → 使用 assets/github-actions-nodejs.yml
- GitLab → 使用 assets/gitlab-ci-nodejs.yml
- CircleCI/Jenkins → 适配GitHub Actions模板
- 不确定 → 查阅 references/platform-comparison.md
- 2. 需要哪些阶段?
- 始终包含:代码检查、测试、构建
- 可选:安全扫描、端到端测试、性能测试
- 如果从CI部署,添加部署阶段
- 3. 哪个部署平台?
- Vercel → 使用Vercel部署示例
- Netlify → 使用Netlify CLI方法
- AWS → 使用AWS Actions/CLI
- 自定义 → 实现自定义部署脚本
- 4. 什么触发条件?
- 推送到main/develop时
- 创建拉取请求时
- 创建标签时
- 手动工作流调度
- 5. 需要哪些环境变量?
- 平台令牌(Vercel、Netlify、AWS)
- 外部服务的API密钥
- 构建时环境变量
- 功能标志
最佳实践
安全性
- - 将所有密钥存储在平台密钥管理中(切勿在代码中)
- 使用最小权限令牌(尽可能只读)
- 定期轮换密钥
- 审计密钥访问权限
- 切勿记录密钥(使用 * 掩码)
性能
- - 积极缓存依赖
- 并行化独立作业
- 使用矩阵构建进行多版本测试
- 快速失败:在慢速检查之前运行快速检查
- 优化Docker层缓存
可靠性
- - 锁定精确的Node.js版本(18.x 而不仅仅是 18)
- 提交锁定文件(package-lock.json)
- 为不稳定的外部服务添加重试逻辑
- 设置合理的超时时间(最多10-15分钟)
- 对非关键步骤使用 continue-on-error
可维护性
- - 添加注释解释复杂逻辑
- 使用可重用工作流/模板
- 保持配置DRY(不要重复自己)
- 对所有管道更改进行版本控制
- 在README中记录所需的密钥
常见模式
多环境部署
yaml
deploy_staging:
environment: staging
if: github.ref == refs/heads/develop
deploy_production:
environment: production
if: