CI/CD Pipeline

Design and implement efficient, secure, and reliable CI/CD pipelines.

When to Use

• User asks to set up, optimize, or troubleshoot CI/CD pipelines
• Configuring workflow triggers or managing secrets in pipelines
• Handling pipeline failures or implementing deployment strategies
• Even if they just say "set up CI" or "fix the pipeline"

Platform Comparison

Pipeline Design Workflow

1. Define triggers — Push, PR, schedule, or manual dispatch. Use paths filters to skip unnecessary runs.
2. Structure jobs — Separate lint, test, build, and deploy into distinct jobs. Use dependencies for ordering.
3. Add caching — Cache dependencies (npm, pip, cargo) between runs. Reduces build times 30-70%.
4. Manage secrets — Never hardcode tokens. Use platform secret stores and rotate regularly.
5. Add security scanning — Run SAST, dependency scanning, and secret detection in CI.
6. Configure notifications — Alert on failures to Slack, Discord, or email.

Common Failure Patterns

Gotchas

• GitHub Actions GITHUB_TOKEN expires after 1 hour — don't use it for long-running workflows.
• GitLab CI rules: and only/except are mutually exclusive — pick one per job.
• Forgejo Actions are compatible with GitHub Actions syntax but may lag behind on new features.
• Matrix builds multiply cost — a 3x3 matrix runs 9 jobs, not 3.
• Artifact retention defaults vary by platform — set explicit retention to avoid storage costs.

Coverage Integration

Generate Coverage Reports

JavaScript/TypeScript (Jest):

{ "collectCoverage": true, "coverageReporters": ["lcov"] }

Python (pytest):

pytest --cov --cov-report=xml:cobertura.xml

Go:

go test -coverprofile=coverage.out ./...

Java (Maven + JaCoCo): Add JaCoCo plugin to pom.xml, then:

mvn test jacoco:report

Upload Coverage to Codacy

bash <(curl -Ls https://coverage.codacy.com/get.sh) report -r <coverage-report-file>

GitHub Actions:

- name: Upload coverage to Codacy
  env:
    CODACY_PROJECT_TOKEN: ${{ secrets.CODACY_PROJECT_TOKEN }}
  run: bash <(curl -Ls https://coverage.codacy.com/get.sh) report -r coverage.xml

GitLab CI:

upload-coverage:
  stage: test
  script:
    - bash <(curl -Ls https://coverage.codacy.com/get.sh) report -r coverage.xml
  variables:
    CODACY_PROJECT_TOKEN: $CODACY_PROJECT_TOKEN

Multiple reports (monorepos):

bash <(curl -Ls https://coverage.codacy.com/get.sh) report --partial -r report1.xml
bash <(curl -Ls https://coverage.codacy.com/get.sh) report --partial -r report2.xml
bash <(curl -Ls https://coverage.codacy.com/get.sh) final

Key notes:

• Coverage must be uploaded for every push to be useful for PR analysis
• File paths in reports must be relative to repository root
• Set CODACYPROJECTTOKEN as a CI/CD secret (from Codacy > Repository Settings > Coverage)

Rationalizations

Red Flags

• Hardcoding secrets or tokens in workflow files
• Skipping security scanning in CI for speed
• Not caching dependencies between pipeline runs
• Using actions/checkout@v3 instead of @v4 (missing security fixes)

References

• [Performance Checklist](../../../agents-docs/references/performance-checklist.md) - CI/CD optimization patterns, caching strategies, and runner sizing.
• references/deployment-strategies.md - Blue-green, canary, and rolling deployments.
• references/failure-recovery.md - Handling pipeline failures and rollbacks.
• references/security-scanning.md - Integrating security tools into pipelines.

See Also

• git-github-workflow — Full commit-to-merge lifecycle including CI monitoring
• github-pr-sentinel — Specialized PR monitoring with CI failure diagnosis

Voice & Context

• Default: professional + blog
• Reference: voice-profiles skill for definitions and auto-detection.