CI/CD Pipelines: Multi-Platform Production Infrastructure

Write, review, and architect CI/CD pipelines across GitHub Actions, GitLab CI/CD, Forgejo Actions, Gitea Actions, and Woodpecker. The goal is secure, fast, auditable pipelines that satisfy both engineering needs and compliance requirements (PCI-DSS 4.0).

Target versions: May 2026 snapshot. Read references/target-versions.md before pinning forge, runner, CI, or supply-chain tool versions.

This skill covers workflow design, security, compliance, cross-platform migration, runners, dependency updates, scanning, review gates, and rollout order.

When to use

• Writing or reviewing CI/CD pipeline configs (GitHub/Forgejo/Gitea Actions, .gitlab-ci.yml, .woodpecker/*.yaml)
• Designing pipeline architecture (stages, parallelism, caching, deployment strategies)
• Hardening pipelines against supply chain attacks (SHA pinning, image signing, provenance)
• Setting up security scanning in CI (SAST, SCA, container scanning, secret detection)
• Configuring runners (install, register, executor choice, hardening) - see references/runners.md
• Setting up caching strategies or artifact management
• PCI-DSS 4.0 compliance for CI/CD (Req 6.2.1, 6.2.4, 6.3.2, 6.4.2, 6.5.3)
• Migrating pipelines between platforms (GitLab -> GitHub, GitHub -> Forgejo)
• Troubleshooting failed pipelines, flaky jobs, or runner issues

When NOT to use

• Kubernetes manifests, Helm charts, cluster architecture - use kubernetes
• Dockerfiles, Compose stacks, container image optimization - use docker
• Terraform/OpenTofu infrastructure-as-code - use terraform
• Ansible playbooks, configuration management - use ansible
• Security audits of application code (SAST findings, auth bugs) - use security-audit
• Code review of pipeline-adjacent code (the app itself) - use code-review
• The code-review skill has a cicd-pipelines.md reference for bug patterns in existing pipelines. This skill is for writing and architecting pipelines.

AI Self-Check

AI tools consistently produce the same CI/CD mistakes. Before returning any generated pipeline config, verify against this list.

Review mode: if auditing an existing pipeline rather than generating one, invert this checklist - each item that fails is a finding. Work through the list top-to-bottom and report every failure with file and line reference.

• SHA pinning: all third-party actions/images pinned to full commit SHA or digest, not mutable tags. Add # vX.Y.Z comment for readability.
• Permissions: explicit permissions: block on every GitHub Actions workflow (read-only default). GitLab: protected variables scoped correctly.
• No secrets in config: no hardcoded tokens, passwords, or API keys. Use CI/CD secret variables or vault integration.
• No latest tags: runner images, tool images, and base images pinned to specific versions or SHA256 digests.
• Caching strategy: dependencies cached correctly (lockfile-based keys), build outputs use artifacts (not cache).
• Fail-fast security: SAST, dependency scanning, and secret detection run early (not after deployment).
• Manual gates for production: production deployments require explicit approval (not auto-deploy on merge).
• SBOM generation: release pipelines generate and attach SBOMs (SPDX or CycloneDX). Required for PCI-DSS 4.0.
• Minimal scope: jobs have minimum required permissions, access only needed secrets, and run only needed steps.
• No allow_failure without justification: if a job can fail, explain why in a comment.
• Version pinning on tools: node:22, not node:lts. python:3.13, not python:3. Specific versions prevent silent breakage.
• Trigger scoping: on: push without branch/path filters runs on every push to every branch - scope to branches: [main] and/or paths: filters. Same for GitLab: rules: with if conditions, not bare only: [pushes].
• No expression injection (GitHub Actions): ${{ }} expressions never used directly in run: blocks. Assign to env: first. github.event.* is attacker-controlled. Avoid github.ref_name in security-sensitive contexts (injectable via crafted tag/branch names).
• Self-hosted runners ephemeral on public/untrusted repos: non-ephemeral shell runners on repos that accept outside PRs is the top self-hosted-runner compromise vector. Verify --ephemeral (GitHub, Gitea) or capacity-based single-job runners (Forgejo) + approval gates for outside contributors. See references/runners.md.
• Docker socket mount scope: /var/run/docker.sock mounted into a job gives it root on the host. Only acceptable for trusted internal pipelines. Public/shared runners need DinD sidecar or rootless buildkit instead.
• Scan gate has a baseline, not a blanket block: container/IaC/SAST scanners introduced with exit-code 1 and zero suppression always get disabled. Use the ratchet pattern (non-blocking -> baseline -> block new only) from references/best-practices.md.
• Ignore-list entries have expiry dates: every .trivyignore, .grype.yaml, Dependabot ignore, or Renovate ignoreDeps entry includes a comment with revisit date + owner. No dates = zombie tech debt.
• Lockfiles committed: package-lock.json, bun.lock, Cargo.lock, go.sum, uv.lock belong in version control for applications. Manifest-only commits break reproducibility.
• Auto-merge gated on tests, not just lint: Dependabot/Renovate auto-merge without test coverage of the changed area is a supply-chain shortcut.
• Current source checked: dated versions, CLI flags, API names, and support windows are verified against primary docs before repeating them
• Hidden state identified: local config, credentials, caches, contexts, branches, cluster targets, or previous runs are made explicit before acting
• Verification is real: final checks exercise the actual runtime, parser, service, or integration point instead of only linting prose or happy paths
• Routing overlap checked: overlapping skills, trigger terms, and "When NOT to use" boundaries are checked before returning guidance
• Spec claims verified: claims about tool behavior, output contracts, or repo conventions are checked against current docs, scripts, or skill files
• Runner trust checked: workflow advice distinguishes hosted, self-hosted, fork, and protected-branch execution
• Mutable references controlled: actions, images, includes, and templates are pinned where supply-chain risk matters

Performance

• Key caches by lockfiles and toolchain versions; avoid broad caches that restore stale dependencies.
• Split quick lint/unit gates from slow integration, image, and deployment jobs.
• Use path filters and matrix limits to keep monorepo pipelines proportional to the change.

Best Practices

• Use OIDC or short-lived federation for cloud deploys instead of long-lived static secrets.
• Keep pull-request workflows from forks read-only unless explicitly isolated.
• Generate provenance or attestations for release artifacts where the forge supports it.

Workflow

Step 1: Identify the platform

If unclear, ask. The platforms have significant differences despite surface similarity.

Step 2: Determine the domain

• "Create a CI pipeline for my project" -> Workflow d