Pack CI/CD — Del Primer Workflow al Deploy Gate

What's in this pack

Most CI/CD how-tos hand you a 200-line .github/workflows/ci.yml and call it done. That works for a hobby project — it does not work for a real pipeline that has to survive matrix builds, slow caches, leaked secrets, and a 2 a.m. failed deploy. This pack is the opposite angle: ten open-source picks installed in a deliberate order, each one earning its place by solving a problem the previous step exposed.

Every pick is open-source, actively maintained, and produces a config file an AI agent can read, generate, or debug. No hosted-only black boxes. By the end you have a pipeline that runs locally, runs in CI, caches aggressively, scans for secrets, and only ships green builds.

Install in this order

1. actionlint — Lint your workflow YAML before you push. Catches typos in uses:, broken if: expressions, and bad shell escapes that would otherwise burn a 4-minute CI run. Run as a pre-commit hook. Zero excuses.
2. act — Run GitHub Actions locally in Docker. The single biggest CI iteration killer is the commit → push → wait 5 min → see red → repeat loop. act cuts that to seconds. Pair with actionlint and you debug workflows the way you debug code.
3. Super-Linter — Drop-in multi-language linter aggregator from GitHub. One step in your workflow, 50+ linters under the hood (shellcheck, hadolint, yamllint, eslint, ruff). Stops style debates by making the CI the source of truth.
4. BuildKit — Modern OCI image builder with parallel layers and cache-mount support. Once your build runs through BuildKit, RUN apt-get and RUN npm ci survive across commits via --mount=type=cache. Typical CI cuts: 8 min → 90 sec for a Node + Python service.
5. Dagger — Programmable CI/CD engine: pipelines as actual code (Go, Python, TypeScript), runs identically on GitHub Actions, GitLab CI, Buildkite, or your laptop. The moment your .yml exceeds 300 lines, you reach for Dagger and never look back. Provider lock-in goes away in one afternoon.
6. Concourse — Container-native CI with declarative pipelines for self-hosted setups. When you can't put proprietary code on hosted CI, Concourse is the sane open-source alternative. Pipelines live in YAML, every step is a container, state lives in S3 or a PG.
7. Gitleaks — Static secret scanner. One step in your pipeline that fails the build if an AWS key, GitHub token, or JWT slips into a commit. Catches the 5% of secret leaks that all the careful coding in the world won't prevent.
8. sops — Mozilla's encrypted-file secrets manager. Commit secrets.enc.yaml to git, decrypt at deploy time with KMS / age / PGP. Tiny, no service to run, perfect for the 80% of teams that don't yet need Vault.
9. Infisical — Open-source secret management service when sops stops scaling. Web UI, role-based access, CI integrations for GitHub Actions / GitLab / Vercel. The graduation path from sops, before you reach for HashiCorp Vault.
10. Kamal — Zero-downtime Docker deploy tool. After CI passes, Kamal handles the rolling deploy with health checks across one or many servers. Replaces the messy ssh && docker pull && docker restart script every team writes and regrets.

How they fit together

Write workflow.yml
   │
   ├─ actionlint  (local, pre-commit)
   │
   ├─ act         (local, docker-compose for CI)
   │
CI runs ──┐
          ├─ Super-Linter step           (style + correctness)
          ├─ BuildKit step               (cached docker build)
          ├─ Dagger pipeline             (portable across providers)
          │     └─ or Concourse          (self-hosted alt)
          ├─ Gitleaks scan step          (block on secret leak)
          └─ sops decrypt step           (inject secrets at runtime)
                 └─ Infisical (if team > 5 people)
                       │
                       ▼
                  Kamal deploy            (zero-downtime gate)

The actionlint + act + Super-Linter triad is the cheap-but-massive iteration win — most teams skip it and waste hours on red CI per week. The Dagger + BuildKit pairing is the long-term lock-in escape: if your CI YAML feels brittle, this is the rewrite path. sops first, Infisical when you grow is the right secrets ramp; jumping straight to Vault for a 3-person team is YAGNI in cardboard armor.

Tradeoffs you'll hit

• act vs hosted runners — act is great for 80% of workflow debugging but doesn't perfectly emulate GitHub-hosted runner features (matrix expansion edge cases, OIDC tokens, hosted-only services). Use it for iteration, then verify on real CI before merging the workflow change.
• Dagger vs raw YAML — Dagger adds a language layer (Go/Python/TS) on top of CI. Worth it past ~300 YAML lines or when you need to run the same pipeline across providers. For a single-file 50-line workflow, raw YAML is still right.
• sops vs Infisical vs Vault — sops = files in git, no service. Infisical = web UI + RBAC, one service. Vault = full-blown secrets platform with dynamic credentials, multiple services. Pick the smallest that solves your problem this quarter.
• Kamal vs Kubernetes — Kamal is for teams that want zero-downtime Docker deploys without running k8s. The moment you need autoscaling, scheduled jobs, or service mesh, you're outside its target. Don't fight that boundary.
• Concourse vs GitHub Actions — If you can use hosted CI, do. Concourse is for when compliance, air-gap, or cost forces self-hosted. Operating a Concourse cluster has real ops overhead.

Common pitfalls

• No cache key strategy — actions/cache with the wrong key invalidates every run. Hash the lockfile (package-lock.json, poetry.lock), not the source tree.
• Matrix builds with fail-fast: true — by default GitHub kills the whole matrix on first failure. Set fail-fast: false when you want to see all OS / version failures at once for triage.
• Secrets in env at the workflow level — anything in env: at the job level is visible to every step, including third-party actions. Inject secrets only into the specific step that needs them.
• Forgetting concurrency: — without a concurrency group, two pushes to the same branch run two deploys in parallel and race. Add concurrency: { group: deploy-${{ github.ref }}, cancel-in-progress: true }.
• Gitleaks with no allowlist — first run will flag test fixtures and example tokens. Curate the .gitleaks.toml allowlist once, then it stays useful instead of being muted.
• Kamal without a healthcheck endpoint — Kamal's zero-downtime relies on /up returning 200 before traffic switches. Skip that and you get downtime-ish deploys instead.