Overview

This document outlines the Continuous Integration (CI) process for Pull Requests at DEVOPS. The CI pipeline is designed exclusively for testing pull requests - it does NOT perform any deployment or continuous delivery (CD) operations. The pipeline automatically triggers when developers create pull requests, running tests and validations to ensure code quality before merging.

Important Scope Clarification

What this CI pipeline DOES: ✅ Automatically triggers on pull request creation/updates ✅ Builds and tests code in isolated environments ✅ Runs unit tests, security scans, and code quality checks ✅ Provides reports to Developers/QA via Slack/email ✅ Updates PR status with test results

What this CI pipeline DOES NOT do: ❌ Push images to production registries ❌ Deploy to any environment (dev, staging, or production) ❌ Trigger on merge events or direct pushes to branches ❌ Perform any CD (Continuous Deployment) operations ❌ Make any changes to live systems

After PR is Merged:

• The merged code does NOT trigger automatic deployment
• Deployments are handled manually by building from the merged branch
• This ensures controlled, deliberate deployments with human oversight

Architecture Overview

Pull Request Testing Workflow

1. Developer Creates Pull Request

When a developer creates a pull request:

• The pull request MUST follow the naming convention: PR-* (e.g., PR-feature-name)
• Gitea webhook sends pull request events only to Jenkins
• Jenkins receives the event and initiates the testing pipeline only
• No deployment actions are triggered at any point

Important:

• Pull requests that don’t start with PR-* will not trigger the CI pipeline
• This pipeline ONLY runs for pull requests, NOT for direct pushes or merges