Pre-CI: General CI/CD Pipeline Architecture and Pre-checks
📚 Series: CI/CD and AI: From Theory to Practice
Before Continuous Integration (CI) there is a set of stages that ensure the code entering the branch meets minimum standards of quality, style, security, and maintainability before activating the CI/CD pipeline.
Parts of this block:
- Part 1 — General architecture and PR Checks ← you are here
- Part 2 — CI: analysis, tests, quality, and security
Table of Contents
General CI/CD pipeline architecture
Before going into detail on each phase, it is useful to have a high-level view of the complete flow. The general idea is:
In summary:
| Phase | What it does | What it does NOT do |
|---|---|---|
| PR Checks (Pre‑CI) | Fast validations | Nothing that takes more than 1–3 min |
| CI | Code tests | Nothing that requires Docker or real network |
| CD | Real service tests | Nothing internal to the code |
This will be the complete CI/CD architecture we will follow:
PR Checks (Pre-CI)
Only if the PR (pull request) passes this phase does it enter CI. There are therefore some checks that are interesting to run before the CI/CD pipeline starts. Nothing that would be done completely or in depth in CI/CD should be done here — only some extremely fast checks or those that have no place anywhere else make sense.
This block is the phase before CI, where:
- everything must be fast (more than 1 minute can already be considered slow)
- everything must be deterministic
- nothing should spin up containers
- nothing should run heavy builds
- nothing should depend on external infrastructure
It is the phase that filters:
- poorly formatted code
- poorly defined PRs
- changes that break contracts
- trivial errors
- style problems
- basic vulnerabilities
- semantic inconsistencies detected by AI
Steps / Checks included
1) Static Analysis — fast mode
This is a lightweight static analysis with basic rules and fast execution.
We will detail this further when we talk about “Static Analysis — Deep mode”.
It is fast and prevents obviously incorrect code from reaching CI.
Detects:
- simple vulnerabilities
- obvious dangerous patterns
- basic quality errors
- evident code duplication
- trivial bad practices
Does not:
- deep analysis
- full SAST (Static Application Security Testing)
- full SCA (Software Composition Analysis)
- advanced semantic analysis
Examples:
- SonarQube PR mode
- Semgrep light rules
- Checkmarx Express
2) Quick linting (optional)
Running the linter in fast mode, without heavy rules.
It is optional because some teams prefer to run full linting in CI, but including it in PR speeds up feedback.
Detects:
- unused imports
- unused variables
- style errors
- trivial inconsistencies
- formatting issues
Examples:
- ESLint (fast mode)
- Flake8
- Basic Checkstyle
3) Format validation (Prettier, Spotless)
Automatic validation of code format according to the team’s rules.
It is instantaneous and avoids PRs with unnecessary noise.
Detects:
- incorrect quotes
- incorrect indentation
- extra spaces
- inconsistent line breaks
- non-standardized formatting
Examples:
- Prettier (JS/TS)
- Spotless (Java/Kotlin)
- Black (Python)
4) Convention validation (names, commits, PR template)
Automatic validation that the PR meets the team’s standards.
Avoids poorly defined PRs that are hard to review or lack context.
Validates:
- PR name
- commit format (Conventional Commits)
- mandatory labels
- mandatory description
- PR template checklist
- Jira ticket reference
Examples:
- commitlint
- Danger.js
- GitHub Actions with custom rules
5) OpenAPI/gRPC validation (if applicable)
Validation that API changes comply with the contract.
It is fast and avoids breaking other teams before entering CI.
Validates whether changes:
- comply with the contract
- do not break compatibility
- follow the team’s rules
- do not introduce breaking changes
Detects:
- undocumented changes
- new routes without specification
- incompatible model changes
- schema errors
Examples:
- OpenAPI Diff
- gRPC Contract Validator
- Spring Cloud Contract (stub mode)
6) Fast unit tests (optional)
Running a selection of fast unit tests, without spinning up heavy context.
It is optional because some teams prefer to run all unit tests in CI, not in PR.
Detects:
- trivial errors
- simple regressions
- failures in pure logic
Recommended for:
- large repos
- frequent PRs
- teams with high turnover
7) AI Pre‑Review (optional)
An automatic AI review of the PR, before the human review.
It is optional because it depends on the team’s maturity and AI adoption policy.
Provides:
- explains changes
- detects inconsistencies
- suggests improvements
- identifies risks
- proposes refactors
- detects semantic duplication
- reviews names, patterns, and style
Does not:
- approve the PR
- replace the human review
- run tests
PR Checks comparison table
| Phase | Goal | Type |
|---|---|---|
| Fast Static Analysis | detect trivial problems | mandatory |
| Quick linting | basic style | optional |
| Format validation | consistent formatting | mandatory |
| Convention validation | clean and correct PR | mandatory |
| OpenAPI/gRPC validation | avoid breaking changes | if applicable |
| Fast unit tests | detect trivial regressions | optional |
| AI Pre‑Review | intelligent suggestions | optional |
