GitLab CI

Introduction

GitLab CI is a practical Selenium skill for teams turning Selenium into a release confidence system. Instead of learning it as a command, learn the release problem it solves, the failure it prevents, and the framework decision behind it.

Purpose of this lesson

Story: A Jenkins job showed red for weeks but nobody trusted it. Once smoke/regression tiers and screenshots were added, failures became actionable. In this lesson, gitLab CI runs browser tests as versioned pipeline jobs. The goal is to make Selenium feel like engineering, not record-and-playback automation.

Understanding the topic

Why this exists: GitLab CI runs browser tests as versioned pipeline jobs. CI/CD decides when automation runs, what evidence is published, and whether a release should continue.

• Real problem solved: GitLab CI reduces manual regression cost, flaky feedback, or debugging ambiguity.
• Production use: Jenkins, GitHub Actions, Azure DevOps, GitLab CI, Docker runners, nightly suites, and release gates.
• Beginner misuse: Running one giant suite everywhere and ignoring red builds because they take too long.
• Expert move: Split execution into fast PR smoke, scheduled regression, release validation, and quarantined flaky-watch suites.

Visual explanation

Mental model:

Commit
  ↓ smoke
Merge
  ↓ regression
Release
  ↓ cross-browser
Artifacts
  ↓ report + logs + screenshots

Informative example

A practical Java + Selenium example for GitLab CI:

mvn test -Dgroups=smoke -Dbrowser=chrome -Dscenario=gitlab-ci
# archive reports/
# archive screenshots/
# notify team with failure category

Execution workflow

Real-world use

In real teams, GitLab CI becomes valuable when it gives a trustworthy signal under product change. The lesson is not “how to use one API”; it is how to design a check that survives browser differences, frontend re-renders, test data changes, and CI timing pressure.

Best practices

• Publish reports and screenshots as artifacts.
• Parameterize browser/environment from pipeline config.
• Keep PR feedback fast.
• Track flaky retry rate over time.

Common mistakes

• No artifacts after failure.
• Hard-coded local paths in CI.
• Shared credentials causing parallel failures.

Debugging tips

• Compare CI browser, driver, Java, and dependency versions.
• Check agent resources and display/headless configuration.
• Inspect first failure artifact before rerunning.

Advanced interview questions

Summary

GitLab CI becomes valuable when it protects a real release, shortens feedback, and stays maintainable as the product changes.