CI/CD Pipeline Overview

Every push to a CWIQ repository triggers a CI/CD pipeline on GitLab. Pipelines run on Kubernetes-based runners on AWS EKS.

Pipeline Stages

validate → test → build → release → deploy-dev → verify

Stage	What Happens
validate	Linting (Ruff, ESLint), type checking (mypy, TypeScript), Terraform validate
test	Unit tests (pytest, Vitest), security scans (Semgrep, Trivy)
build	Docker image build (Kaniko), RPM build (Nuitka for executor)
release	GitLab release creation (on version tags only)
deploy-dev	Deploy to DEV environment (automatic on main, manual on feature branches)
verify	Health checks, smoke tests, E2E tests

Runner Architecture

Pipelines run on Kubernetes pods in AWS EKS:

Runner Tag	Resources	Used For
small	Default	Most jobs (lint, test, deploy)
medium	More CPU/memory	Docker image builds (Kaniko)
large	Maximum resources	Nuitka compilation, RPM builds

Viewing Pipeline Status

1. Go to your project in GitLab
2. Click Build > Pipelines in the sidebar
3. Each row shows a pipeline with its status (running, passed, failed)
4. Click a pipeline to see individual job logs
5. Click a job to see its console output

Feature Branch Pipelines

• main branch: Full pipeline including automatic deploy to DEV
• Feature branches: Validate + test + build only (no automatic deploy)
• Manual deploy: Feature branches can be deployed to DEV manually via the deploy-dev-standalone job

Docker Image Tags

Trigger	Tags Applied
Push to main	main-{short-sha}, latest
Feature branch	branch-{slug}-{short-sha}
Version tag (v*)	{version}, stable

What Gets Scanned

Every pipeline includes automated security and quality scanning:

Scanner	What It Checks	Results Sent To
Semgrep	SAST — code patterns, vulnerabilities	Pipeline report
Trivy	Dependencies, Docker images, licenses	DefectDojo
SonarQube	Code quality, bugs, code smells	SonarQube
Playwright	E2E browser tests (UI only)	ReportPortal