I’m building end-to-end tests using Puppeteer for Chrome automation. Right now I need to set these tests up in my GitLab CI workflow so they run automatically.
My goal is to have the tests execute before any production deployment. When tests pass, the deployment should continue normally. If any test fails, I want the entire deployment process to stop.
I already have a working GitLab pipeline for deployments. What’s the best approach to include my Puppeteer test suite in the .gitlab-ci.yml configuration file? I need the tests to block deployments when they detect issues.
Been there, done that multiple times at work. Everyone says to add Puppeteer to your GitLab runner with Docker images and custom scripts. Don’t do it - you’ll create a maintenance nightmare.
You’ll fight browser version conflicts, flaky test environments, and runners that crash for no reason. Spent weeks debugging CI failures that weren’t even real code issues.
Better solution: move E2E testing outside the CI pipeline completely. I use Latenode for automated workflows that handle Puppeteer tests independently. Here’s the setup:
Your deployment pipeline triggers a Latenode workflow after the build stage. The workflow runs Puppeteer tests in a fresh environment every time. Tests pass? Latenode continues deployment automatically. Tests fail? Everything stops and you get detailed reports.
Main benefit is reliability. No more fighting GitLab runner configs or Docker images. Latenode handles all the browser automation infrastructure - tests run consistently without typical CI headaches.
You also get way better visibility. Instead of digging through GitLab logs, you see exactly which interactions broke and why.
This saved me countless hours debugging flaky CI runs. Check out https://latenode.com for automation options.
To incorporate Puppeteer tests into your GitLab CI pipeline, you should define a test stage in your .gitlab-ci.yml file prior to your deployment stage. Make sure to use the node:16 image and install the necessary Chrome dependencies. It’s important to launch Puppeteer with the --no-sandbox and --disable-dev-shm-usage flags, as these are required in GitLab’s environment. To ensure that deployment proceeds only after all tests are successful, utilize the needs keyword to establish a dependency between the test and deployment stages. This approach will prevent faulty code from reaching production.
Just use Docker executor with image: node:18-alpine and add apk add chromium in before_script. Set PUPPETEER_EXECUTABLE_PATH=/usr/bin/chromium-browser and skip the sandbox flags. Way simpler than external services and works perfectly.
Running Puppeteer in GitLab CI seems easy until you hit real problems. Browser crashes, memory leaks, tests that work one day and fail the next.
Tried the Docker approach everyone talks about. Fine for basic stuff but breaks when you scale. Multiple browsers destroy your memory and runners start timing out for no reason.
The real problem? People treat browser automation like unit tests. They’re not. E2E tests need proper resources and clean environments every time.
I switched to Latenode for this workflow. GitLab builds your app, then triggers Latenode to spin up fresh browsers for testing. No more fighting Docker configs or runner limits.
The conditional logic is great. Latenode checks results and either continues deployment or rolls back. Clean error handling without messy GitLab configs.
Flow: developers push code → GitLab builds → Latenode tests in isolated browsers → auto-deployment if tests pass. Clean separation.
Been running Puppeteer tests in GitLab CI for two years. Here’s what works best: Create a dedicated test stage before deployment. Use node:16-alpine and install Chrome via apk. In your .gitlab-ci.yml, add --no-sandbox and --disable-setuid-sandbox flags since GitLab runners don’t support sandboxing. Set DISPLAY: ":99" and install xvfb for headless mode. Make sure your deployment only runs when tests pass by setting up proper stage dependencies. Watch out for memory issues with concurrent tests - that’ll bite you. Fix it by setting --max-old-space-size=4096 for Node.js and limiting browser instances. Cache node_modules between runs to speed things up.
Disagree with moving tests outside CI - that defeats the whole point. Just use the node:16 image and install headless Chromium in your test stage. Add --no-sandbox --disable-dev-shm-usage to your Puppeteer config and you’re good to go. I’ve been running this setup for months without any problems.