# CI Job Status Configuration

This document explains which CI jobs should fail on errors and which are informational.

## Jobs That Should FAIL on Errors ✅

These jobs will show a **red X** if they encounter errors:

### 1. **lint-and-type-check**
- ✅ ESLint (admin-frontend) - **FAILS on lint errors**
- ✅ Type check (viewer-frontend) - **FAILS on type errors**
- ⚠️ npm audit - **Informational only** (continue-on-error: true)

### 2. **python-lint**
- ✅ Python syntax check - **FAILS on syntax errors**
- ✅ Flake8 - **FAILS on style/quality errors**

### 3. **test-backend**
- ✅ pytest - **FAILS on test failures**
- ⚠️ pip-audit - **Informational only** (continue-on-error: true)

### 4. **build**
- ✅ Backend validation (imports/structure) - **FAILS on import errors**
- ✅ npm ci (dependencies) - **FAILS on dependency install errors**
- ✅ npm run build (admin-frontend) - **FAILS on build errors**
- ✅ npm run build (viewer-frontend) - **FAILS on build errors**
- ✅ Prisma client generation - **FAILS on generation errors**
- ⚠️ npm audit - **Informational only** (continue-on-error: true)

## Jobs That Are INFORMATIONAL ⚠️

These jobs will show a **green checkmark** even if they find issues (they're meant to inform, not block):

### 5. **secret-scanning**
- ⚠️ Gitleaks - **Informational** (continue-on-error: true, --exit-code 0)
- Purpose: Report secrets found in codebase, but don't block the build

### 6. **dependency-scan**
- ⚠️ Trivy vulnerability scan - **Informational** (--exit-code 0)
- Purpose: Report HIGH/CRITICAL vulnerabilities, but don't block the build

### 7. **sast-scan**
- ⚠️ Semgrep - **Informational** (continue-on-error: true)
- Purpose: Report security code patterns, but don't block the build

### 8. **workflow-summary**
- ✅ Always runs (if: always())
- Purpose: Generate summary of all job results

## Why Some Jobs Are Informational

Security and dependency scanning jobs are kept as informational because:
1. **False positives** - Security scanners can flag legitimate code
2. **Historical context** - They scan all commits, including old ones
3. **Non-blocking** - Teams can review and fix issues without blocking deployments
4. **Visibility** - Results are still visible in the CI summary and step summaries

## Database Creation

The `|| true` on database creation commands is **intentional**:
- Creating a database that already exists should not fail
- Makes the step idempotent
- Safe to run multiple times

## Summary Step

The test results summary step uses `|| true` for parsing errors:
- Should always complete to show results
- Parsing errors shouldn't fail the job
- Actual test failures are caught by the test step itself


