Back to project archive

07 · CI engineering · Browser quality gates

Jenkins Selenium Delivery Pipeline

A parameterised Jenkins pipeline that can move from fast code checks to local or cloud browser acceptance tests while keeping secrets and failure evidence under control.

3selectable test suites
2execution targets
2desktop browser choices
1–4selectable worker count

One pipeline, several legitimate ways to run it

A useful browser-testing job needs different modes. A quick smoke run should not require the same time or infrastructure as a full regression suite, and a local browser should be replaceable with a remote grid without maintaining a second pipeline.

The declarative Jenkinsfile exposes those decisions as validated parameters while keeping the build stages consistent.

The pipeline treats test results and diagnostic artifacts as delivery outputs, not console noise someone must reconstruct after the build.

Useful flexibility without arbitrary combinations

SUITE

Smoke, regression or mobile

The requested depth is chosen at build time.

TARGET

Local or LambdaTest

The same acceptance layer can use the agent browser or a remote grid.

BROWSER

Chrome or Firefox

Desktop browser selection is explicit and visible in the run.

WORKERS

One, two or four

Parallelism is constrained to known values rather than free text.

The validation stage rejects unsupported combinations such as mobile with Firefox before expensive setup begins. Failing early makes the reason clear and saves executor time.

A delivery path that reads like the investigation path

01
Validate and check outReject invalid parameters before touching the test environment.
GUARD
02
Create an isolated environmentInstall the repository’s Python dependencies repeatably.
PREPARE
03
Lint and run unit testsFast feedback arrives before browser execution.
CHECK
04
Route acceptance testsLocal Selenium or the configured LambdaTest session.
VERIFY
05
Publish and cleanKeep the evidence; remove disposable workspace state.
CLOSE

The repository includes a Dockerfile, Compose configuration and pinned Jenkins plugins so the controller and browser-ready agent can be reproduced instead of being described only in screenshots.

Artifacts designed for the failed build

JUnit output gives Jenkins structured test status. The HTML report supports human review, while screenshots and page source preserve the browser state that caused an acceptance check to fail.

Artifacts are fingerprinted and retained under an explicit policy. Publishing runs after failure, because that is exactly when the diagnostic record matters.

JenkinsDeclarative pipelineDockerPythonpytestSelenium 4JUnitLambdaTest

Cloud execution without credentials in source

Remote-grid credentials are injected through Jenkins credentials binding. They do not belong in the repository, generated command text or archived output.

A production extension would add role-based folder permissions, external secret rotation, distributed agents and trend reporting across builds. The current project establishes the core boundary: configuration can vary, but secrets and quality gates remain controlled.

Next case studyMegaWidget Cashflow Model