ci-cd-integration

Files (2)

• SKILL.md
• github-actions-templates.md · references/

SKILL.md (first lines)

<objective>
Design CI/CD pipelines for test execution. Covers GitHub Actions and GitLab CI pipeline templates, parallelism and sharding, artifact management, flaky test quarantine, and quality gates. Use this skill over others when the question is about running tests in a pipeline rather than writing them.
</objective>

## Discovery Questions

1. **Which CI platform?** GitHub Actions, GitLab CI, CircleCI, Jenkins? This skill focuses on GitHub Actions and GitLab CI.
2. **What test types need to run?** Unit, integration, E2E, visual regression, performance? Each has different resource and timing needs.
3. **What is the current CI duration?** If over 10 minutes, parallelism and sharding are essential.
4. **How many developers push per day?** High-frequency teams need aggressive concurrency controls and caching.
5. **What triggers should run which tests?** Not every push needs a full E2E suite.
6. **Check `.agents/qa-project-context.md` first.** Respect existing CI conventions and infrastructure constraints.

---

## Core Principles

1. **Fast feedback: right tests at the right time.** Unit tests on every push (under 2 min). E2E on PRs (under 10 min). Full suite on merge and nightly.
2. **Parallel first: shard tests across workers.** A 20-minute serial suite becomes 5 minutes across 4 shards. Always worth the runner cost.
3. **Artifacts are evidence.** Every CI run must store traces, screenshots, coverage reports, and HTML reports. Without artifacts, CI failures are undebuggable.
4. **Flaky tests need quarantine, not retries.** Retrying hides the problem. Move flaky tests to a separate non-blocking job, track them, and fix them.
5. **Quality gates at every stage.** Define what must pass before code moves forward. Gates get stricter as code gets closer to production.

---

> **Calibrate to your team maturity** (set `team_maturity` in `.agents/qa-project-context.md`):
> - **startup** — Single pipeline job: lint + unit tests + one E2E smoke test on PR. Fast feedback over completeness.
> - **growing** — Separate jobs for unit, integration, E2E. Parallelization, artifact uploads, test result publishing, flaky test quarantine.
> - **established** — Full matrix: parallelized E2E sharding, multi-environment promotion gates, performance and security scans, deployment-gated quality checks, SLA-backed pipelines.

---

## Pipeline Architecture

```
Push to branch:
  ┌─────────────┐
  │ lint + types │  (30s)
  └──────┬──────┘
         │
  ┌──────▼──────┐
  │  unit tests  │  (1-2 min)
  └──────┬──────┘
         │ (pass)
         ▼
  PR opened/updated:
  ┌──────────────┐
  │  integration  │  (2-3 min)
  └──────┬───────┘
         │
  ┌──────▼──────────┐
  │  E2E (sharded)   │  (5-8 min)
  └──────┬──────────┘
         │
  ┌──────▼──────┐
  │ merge report │
  └─────────────┘

Merge to main:
  ┌───────────┐  ┌──────────┐  ┌──────────┐
  │  full E2E  │  │  visual   │  │  perf     │
  └─────┬─────┘  └────┬─────┘  └────┬─────┘
        └──────────────┼─────────────┘
                       ▼
                ┌─────────────┐
                │   deploy     │
                └─────────────┘

Nightly (scheduled):
  full suite + security scan + a11y audit + flaky quarantine
```

### What Runs When

| Trigger | Tests | Max Duration |
|---------|-------|-------------|
| Push to branch | lint, type-check, unit | 2 min |
| PR opened/updated | + integration, E2E smoke | 10 min |
| Merge to main | + full E2E, visual, perf budget | 15 min |
| Nightly schedule | full suite, security, a11y, flaky quarantine | 30 min |
| Release tag | full suite, smoke against staging | 20 min |

---

## GitHub Actions Templates

For complete, copy-paste-ready workflow files, see `references/github-actions-templates.md`.

### Key Concepts

**Concurrency groups** prevent wasted runs when a branch gets multiple pushes:

```yaml
concurrency:
  group: tests-${{ github.ref }}
  cancel-in-progress: true
```

**Matrix strategy** for sharding tests across runners:

```yaml
strategy:
  fail-fast: false
  matrix:
    shard: [1, 2, 3, 4]
steps:
  - run: npx playwright test --shard=${{ matrix.shard }}/4
```

**Smarter sharding** — past 10–15 shards, naïve hash-based splitting wastes runner time on uneven shards. Use a balancer:

- **`knapsack-pro`** (timing-data based, supports Playwright/Jest/Cypress/RSpec) — distributes by historical duration.
- **CloudBees Smart Tests** (formerly **Launchable**) — ML-based prioritization + Test Impact Analysis; runs only the tests likely to fail given the diff.
- **Datadog Test Optimization** — TIA + flake management; shard-balancing by historical time.
- **Trunk Flaky Tests** — flake-aware quarantine + retry budgeting.

For self-hosted runners on Kubernetes, use **Actions Runner Controller (`gha-runner-scale-set`)** — Helm-installed, auto-scales runner pods per workflow. Replaces the deprecated `actions-runner-controller/runner-deployment` CRD; current name is `arc-runner-set`.

> **GitHub Actions versioning (May 2026):** the `actions/*` v4 family (`checkout`, `setup-node`, `cache`, `upload-artifact`, `download-artifact`) has rolled to v5/v6/v7/v8 on the Node 24 runner; Node 20 is deprecated on GH-hosted runners. Examples below pin v4/v5 for stability — verify the current major before adopting in new pipelines and use Dependabot to keep them current.

From JaiminVadadoriya/Distributed-Cloud-Storage---Sync-Platform, MIT.

More from JaiminVadadoriya/Distributed-Cloud-Storage---Sync-Platform