Regression testing usually starts with good intentions. At first, it's manageable. A few test cases, a couple of environments, and some manual checks before release.
Then the application grows.
More pages. More components. More releases. Suddenly, that "quick regression" takes half a day - and still manages to miss things.
That's exactly where we stopped trying to scale manual testing and moved to automated regression testing using Cypress and Jenkins CI/CT. This post walks through what actually worked for us, including the trade-offs we hit along the way.
If you're new to this setup, our earlier posts on Visual Testing with Cypress and Setting Up Cypress with Jenkins Pipeline are worth skimming first.
Why Cypress + Jenkins (Instead of Yet Another Tool)
We didn't choose this stack because it was trendy. We chose it because it solved real problems.
- Cypress gives fast, reliable browser-based testing. When something breaks, you usually know why within seconds.
- Jenkins CI/CT fits naturally into existing CI ecosystems. No forced workflows. No vendor lock-in.
- Docker eliminates the classic "works locally, fails on Jenkins" problem.
- Kubernetes lets test execution scale without turning Jenkins nodes into fragile, over-configured machines.
This setup isn't theoretical. It runs our regression suites continuously.
How We Run Cypress Tests in Containers
Instead of running Cypress directly on Jenkins agents, we execute everything inside Kubernetes Pods created dynamically by Jenkins.
Each pod contains two containers, each with a clear responsibility:
-
Cypress container: Uses
cypress/included:latestand does one job - run the tests. - Alpine container: Handles what the Cypress image doesn't: Java for Allure reports, Node utilities, and report generation.
Splitting responsibilities like this kept the pipeline clean and easier to maintain.
Jenkins Pipeline Setup (Kubernetes Agent)
The Jenkinsfile defines:
- Pod configuration
- Docker images
- Memory limits
- Working directories
Memory limits matter more than most teams expect. Visual regression tests can spike usage quickly, and without limits, Kubernetes will remind you the hard way.
Below is the Jenkinsfile that spins up a Kubernetes pod with Cypress and Alpine containers:
pipeline {
agent {
kubernetes {
label 'cypress-initialyze-qa'
yaml """
kind: Pod
metadata:
name: cypress-initialyze-qa
spec:
containers:
- name: cypress-initialyze-qa
image: cypress/included:latest
imagePullPolicy: Always
command: ['cat']
tty: true
workingDir: /home/jenkins/agent/
resources:
requests:
memory: "2Gi"
limits:
memory: "4Gi"
- name: cypress-allure-reports
image: alpine:latest
imagePullPolicy: Always
command: ['cat']
tty: true
workingDir: /home/jenkins/agent/
resources:
requests:
memory: "2Gi"
limits:
memory: "4Gi"
"""
}
}
Automated Triggers with pollSCM
We trigger regression tests using Jenkins’ pollSCM mechanism:
triggers {
pollSCM 'H/3 * * * *' //checks source-code repository every 3 hrs
}This checks the repository every three hours.
Is it the most modern approach? No.
Is it reliable? Absolutely.
For teams without consistent webhook setups - or for legacy repositories - pollSCM still does the job.
Pipeline Stages That Actually Matter
Build Stage: Getting Ready to Test
This stage prepares the environment and avoids unnecessary work:
- Installs Node dependencies
- Reuses cached
node_moduleswhen available - Installs Java and Node in the Alpine container for reporting
Caching alone shaved noticeable time off our builds as the test suite grew.
stages {
stage('Build') {
steps {
container('cypress-initialyze-qa') {
script {
sh 'echo build'
if (fileExists('node_modules')) {
echo 'Using cached node_modules directory'
} else {
sh 'npm i'
}
sh 'curl --version'
sh 'ls -a'
}
} //container
container('cypress-allure-reports') {
script {
sh '''
apk update
apk add openjdk11
apk add nodejs npm
'''
}
}//container
}//steps
}//End: Build
Run Tests Stage: Cypress in Action
This is where the actual regression testing happens:
- Baseline images for visual testing are downloaded
- Screenshots are extracted into expected directories
- Cypress runs via
npm run test
When visual tests fail, the output is usually obvious. You don't need to dig through logs—you can see exactly what changed.
stage('Run Tests') {
steps {
container('cypress-initialyze-qa') {
script {
sh 'echo start tests'
// Fetch baseline images from shared drive
sh 'curl -L -o baseline.zip "https://drive.google.com/"'
sh 'ls -lh baseline.zip'
// Create a baseline directory and unzip the content on it.
sh 'mkdir -p cypress-image-diff-html-report/visual-test/screenshots'
sh 'unzip baseline.zip -d cypress-image-diff-html-report/visual-test/screenshots'
sh 'ls -a cypress-image-diff-html-report/visual-test/screenshots'
// Execute tests
sh 'npm run test'
}
}//container
}//steps
post {
//To display artifacts of the build
always {
archiveArtifacts artifacts: 'allure-results/**'
}
}//post
}//End: Run Tests
Artifacts are archived whether the build passes or fails, which makes debugging far less painful.
Post Stage: Reports People Actually Open
Regardless of test outcomes, the Post stage generates and publishes reports:
- Allure Reports for step-by-step execution details
- Cypress Image Diff Reports for visual comparisons
Both are published directly in Jenkins using the PublishHTML plugin.
post {
success {
cleanWs()
}
always {
container('cypress-allure-reports') {
script {
sh 'echo Generating reports'
// Allure command to run report
sh 'npm run allure:report'
// Allure command to generate report
sh 'npm run generate-test'
}
publishHTML([
allowMissing: false,
alwaysLinkToLastBuild: true,
keepAll: true,
reportDir: 'cypress-image-diff-html-report/',
reportFiles: 'allure-report/index.html,index.html',
reportName: 'Combined Report',
reportTitles: 'Allure Report, Screenshot Comparison Report',
useWrapperFileDirectly: true
])
archiveArtifacts artifacts: 'allure-report/**, cypress-image-diff-html-report/**, visual-test/**'
}//container
}//End: Always
}//post
}//pipeline
What the Jenkins Dashboard Gives You
From the Jenkins UI, teams can:
- See regression status immediately
- Open test and visual reports without downloading anything
- Compare results between builds
- Download archived artifacts for offline review
That visibility changed how often our team actually looked at test results—in a good way.
Final Take
Automating regression testing with Cypress and Jenkins CI/CT, backed by Docker and Kubernetes, didn't just speed things up. It made releases less stressful.
Tests run consistently. Failures are easier to understand. And regressions are caught earlier—often before they reach QA or production.
That's the real win.
Need Help Setting This Up?
If your regression tests are slow, flaky, or skipped entirely before releases, we can help. We build scalable Cypress + Jenkins automation pipelines that teams actually trust.
Reach out to us to start the conversation.