Run Selenium Tests in GitLab CI
To run selenium tests in gitlab ci, add a headless browser service to your pipeline job. Then point your test runner to that remote browser address during the build stage. Most teams start by pulling a ready-made browser container image into their build job. They also pass database keys and app secrets into the runner as job variables. When those pipeline roles or keys are too broad, a broken test script can harm shared staging data. How to run selenium tests in gitlab ci GitLab pipelines use
GitLab CI Security + Just-in-Time Access: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
To run selenium tests in gitlab ci, add a headless browser service to your pipeline job. Then point your test runner to that remote browser address during the build stage. Most teams start by pulling a ready-made browser container image into their build job. They also pass database keys and app secrets into the runner as job variables. When those pipeline roles or keys are too broad, a broken test script can harm shared staging data.
How to run selenium tests in gitlab ci
GitLab pipelines use runners to execute your build and test steps inside isolated containers. For browser testing, your job needs two main parts working together at the same time. First, it needs the runtime container where your test code and language tools live. Second, it needs a browser service container that runs the browser engine and its driver.
GitLab links these two containers together over a local network inside the runner host. Your test script sends browser commands to the service container over a local hostname. Meanwhile, the browser container needs to reach your web app to load pages and click elements. Teams either start the web app inside the same job or point the browser at a staging server.
When tests finish, the runner collects screenshots, logs, and test reports from the job folder. You can set up the pipeline to save these files as build artifacts for later review. This flow lets teams check user journeys on every code push without manual browser checks.
Managing test data and staging access
Browser tests rarely run in a vacuum without touching backend databases or external services. Before a test logs into your web app, the job often seeds a database with test users. After the browser check ends, another script cleans up those test rows to reset the state.
To do this work, teams store database passwords and service keys inside GitLab variables. The runner reads these variables and hands them to the test script at the start of the job. If a developer prints job variables to debug a failing test, those secrets can leak into build logs.
Teams also run into trouble when parallel pipeline jobs share the same staging database. Two browser tests might update the same user account at the exact same moment. This clash causes flaky test failures that waste hours of developer time during code reviews.
GitLab CI Security + Just-in-Time Access: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What native pipeline settings leave open
GitLab gives you protected variables and masked values to guard secrets during a pipeline run. Protected variables only load on trusted branches like your main release branch. Masked variables hide exact secret strings when they appear inside the runner log output.
Still, these native rules only decide which pipeline job gets the secret key at startup. Once the job starts, the runner holds full power to run any query or command that the role allows. Native pipeline settings cannot inspect individual database statements or API requests while the test runs.
If a test cleanup script has a bug, it could drop a shared staging table by mistake. Also, if your staging database holds real customer records, test logs might capture sensitive fields. Masking rules that rewrite emails, phone numbers, card numbers, or national IDs in results help lower this risk. Pairing clean test containers with tight runtime controls keeps your automated browser checks safe and reliable.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev runs beside each supported service as an open-source proxy, a sidecar for your database or API.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
Should I use a service container or install the browser directly?
Using a separate service container is faster and cleaner for most pipeline jobs. It avoids installing heavy browser packages on every single run and keeps your build image small.
Why do my browser tests fail only inside the pipeline?
Pipeline containers have small shared memory limits by default, which can crash modern browsers. You may also need to add explicit wait steps because shared runners run slower than local laptops.
How can I see what happened when a headless browser test fails?
Set up your test framework to take a screenshot and save the page HTML whenever an assertion fails. Then tell your GitLab job to save that output folder as an artifact even when the job fails.