DevOps and CI Integration in Playwright Github Actions - Step by Step

When we start learning Playwright, most of us follow a simple flow:

• Write test

• Open terminal

• Run command → npx playwright test

• See the result on our machine

  
  

This is an important starting point. It helps us understand:

• Playwright basics

• Locators and assertions

• Test execution flow

  
  

👉 But this is local execution only

👉 If tests only run on your laptop → automation is incomplete

It depends on one machine, one person, one environment, and one manual action. If the test runs only on your laptop, then the whole process is still dependent on you. The moment code changes are pushed by someone else, or a team wants consistent feedback, local execution alone is not enough.

So, how do we ensure the same test runs automatically without relying on a single person’s laptop?

To move beyond local testing, we need:

• Code should be in a shared repository (GitHub)

• Tests should run automatically on code push

• Results should be visible to the team

• Execution should not depend on a person

  
  

👉 This is exactly where DevOps and CI/CD come into the picture

What Is DevOps and Why Does It Matter for Test Automation?

Let us simplify the term first.

DevOps is a way of working where:

👉 Development + Operations work together

So that software can be:

• built faster

• tested continuously

• delivered reliably

  
  

From Testing Perspective

DevOps means:

• Code is pushed regularly

• Builds happen automatically

• Tests run automatically

• Bugs are caught early

• Feedback is fast

 DevOps Lifecycle

The DevOps lifecycle is not a straight line. It is a continuous loop. Work moves from planning to coding, then building, then testing, and later toward release, deployment, operations, and monitoring. The feedback from monitoring goes back into the next cycle.

That is why testing is not the last step. It is one of the recurring quality checkpoints inside the loop.

Automation makes this loop faster, more reliable, and repeatable.

So if a developer pushes new code and your Playwright suite runs automatically after that, you are already participating in a DevOps-style workflow.

This is why DevOps matters in automation. It brings testing closer to the actual software delivery process. Testing is no longer a separate activity that happens much later. It becomes part of the development flow itself.

What Is CI?

Continuous Integration means that whenever code changes are pushed to a shared repository, automated checks run automatically.

These automated checks may include:

• build validation

• linting

• unit tests

• API tests

• UI automation tests

  
  

Continuous Integration is the bridge between coding and automated quality validation. Earlier, a tester or developer may have run the tests manually after making changes. With CI, the system itself starts the validation.

Tests should run automatically whenever code is pushed to GitHub.

That automatic execution is usually handled through a workflow.

 CI vs CD

CI (Continuous Integration)

• Code commit

• Build

• Automated tests

• Quality check

  
  

CD (Continuous Delivery / Deployment)

• Package

• Deploy to staging

• Approval

• Production release

CI checks quality. CD moves approved changes closer to users.

Role of Testing in DevOps

Testing is not separate anymore. It is embedded inside the pipeline.

This means that testing acts as a quality gate. If the checks fail, the pipeline should not proceed in the same way as a successful run. If the checks pass, the code is considered healthier for the next stage.

Traditional testing often happened after development.DevOps testing happens with development.

This shift is what makes automation so valuable in modern projects.

👉 Each of these tools can be used to run automated tests as part of a CI pipeline.

What We Will Use in This Post

In this post, we will use GitHub Actions as our CI tool.

Here onwards, we will:

👉 Use GitHub Actions to run our Playwright automated tests

👉 Execute tests for the Demo Store application we built in previous posts

👉 Trigger test execution automatically on code push

Before We Start: GitHub Setup and Code Check-in

Before we discuss CI pipelines, GitHub Actions, or automated execution, there is one practical requirement:

Your Playwright project must already be pushed to GitHub.

That is because CI pipelines do not run from your local VS Code folder. They run from code that exists in a shared repository. GitHub Actions, for example, works on the repository content and workflow files stored in GitHub. GitHub defines a workflow as an automated process configured in a YAML file inside the repository.

Before moving to DevOps, ensure your Playwright framework is already hosted on GitHub.

Step 1: Create a GitHub account

If you do not already have a GitHub account, create one and verify your email. This is your starting point for storing the code centrally and later connecting it with GitHub Actions.

Step 2: Create a repository

Create a new repository for your Playwright project. For learning, it can be public or private, depending on your comfort level.

Step 1: Install Git

👉 Go to: https://git-scm.com

• Click Download for Windows / Mac

• Install with default settings

•  Verify Installation

  Open terminal (VS Code or CMD) and run:

git --version

👉 If installed correctly, you will see something like:

Step 3: Open your Playwright project in VS Code

 

Your project should already be working locally. A typical Playwright learning project may contain a structure like this.We have already built this for our demo store in various posts on this blog

• Tests contain your test specs

• pages contains Page Object Model classes

• helpers contains reusable utilities such as global setup or cleanup helpers

• .env stores sensitive values locally

• playwright.config.ts stores Playwright configuration

Step 4: Initialize Git

Inside the project folder, initialize Git if it is not already initialized.

Step 5: Create .gitignore

Before pushing any code, we must prevent sensitive and unnecessary files from going to GitHub.

A simple .gitignore can contain:

Your .env file should not be committed. Reports and dependency folders should also be excluded from version control, as CI will install dependencies and generate reports fresh on each run.

Step 6: Add the remote repository

Connect your local project to GitHub.

git remote add origin https://github.com/your-username/playwright-learn.git

Step 7: Add, commit, and push code

git add .
git commit -m "Initial Playwright framework setup"
git push -u origin main

Step 8: Verify what is visible in GitHub

When you open the repository, you should see framework files such as:

• tests

• pages

• helpers

• package.json

• playwright.config.ts

  
  

But you should not see .env or allure_reports

Local execution = your laptop

CI execution = shared repository + automated pipeline

The requirement of an automated test run

Now we can clearly define what is required if we want our Playwright test to run automatically:

• The code must exist in a shared GitHub repository,

• The project structure must be committed properly,

• Sensitive data must be kept out of source control,

• The framework must be executable through terminal commands,

• A workflow file must exist to tell GitHub when and how to run the tests.

Where GitHub Actions Fit In

For GitHub-hosted projects, one of the most common CI tools is GitHub Actions. GitHub describes Actions as a way to automate, customise, and execute software workflows directly in the repository. A workflow is defined in YAML and can contain one or more jobs.

GitHub Actions allows us to define workflows that run automatically based on events such as:

• push

• pull_request

• manual trigger

  
  

In simple language, a workflow file tells GitHub:

• When to run

• Where to run

• What steps to execute?

  
  

For Playwright projects, that workflow file is usually stored here:

.github/workflows/playwright.yml

How It Gets Created

Option 1: Auto-generated (Playwright Setup)

When you run:

npm init playwright@latest

👉 Playwright asks:

“Do you want to add GitHub Actions workflow?”

👉 If you select YES:

✔ It automatically creates:

.github/workflows/playwright.yml

Option 2: Manual Creation

You can also create it manually:

1. Create folder:

.github/workflows

2. Create file:

playwright.yml

What Is a YAML File?

A YAML file is a human-readable configuration format commonly used in CI/CD tools. GitHub’s workflow syntax documentation states that workflows are defined in YAML files.

You will often hear both:

• YAML

• YML

Both refer to the same format. The extension can be .yaml or .yml.

In GitHub Actions, workflow files are written in YAML. YAML uses indentation, key-value structure, lists, and nested sections.

A tiny example looks like this:

The most important beginner point is this:

YAML is indentation-sensitive.

Even when the words are correct, bad spacing can break the workflow.

Helpful VS Code Support for YAML

When editing workflow files, good editor support is very useful.

• a YAML extension for syntax help and validation,

  

• GitHub Actions support in VS Code for better workflow editing.

  

  
  

This improves indentation visibility, syntax highlighting, and early detection of simple mistakes.

From Concept to Execution: Running Playwright Tests in CI

So far, we understood:

👉 Why local execution is not enough

👉 What DevOps and CI mean

👉 Why GitHub is required

👉 How to push your Playwright framework

👉 What is YAML file

Now comes the most important part:

👉 Actually making your tests run automatically

What Happens Behind the Scenes in CI?

Before writing any workflow, let us understand something very important.

When GitHub Actions runs your test:

👉 It does NOT use your laptop

Instead:

👉 It creates a fresh virtual machine (runner)

👉 Downloads your code

👉 Installs everything from scratch

👉 Runs your tests

So your framework must be:

✔ Clean

✔ Reproducible

✔ Dependency-driven (not manual setup)

Adding Repository Secrets for Playwright in GitHub Actions

Before running our Playwright tests in CI, we need to handle something very important:

👉 Sensitive data

In our local setup, we may have used:

• username

• password

• API tokens

• environment-specific values

  
  

These are often stored in a .env file.

Why .env Does Not Work in CI

When GitHub Actions runs your workflow:

👉 It creates a fresh machine

That machine:

• does not have your local .env file

• does not know your credentials

• does not share anything from your laptop

  
  

So we need a secure way to provide these values.

GitHub Repository Secrets

GitHub provides a secure mechanism called:

👉 Secrets

These are:

✔ Encrypted

✔ Not visible in logs

✔ Not stored in code

✔ Safe for credentials

Where to Add Secrets (Step-by-Step)

From your repository:

👉 Go to:

Settings → Secrets and variables → Actions

• Click “New repository secret”

• Add Secret Name and Value

  
  

For example:

🔹 Username

• Name: LOGIN_USERNAME

• Value: your actual email/username

  
  

🔹 Password

• Name: LOGIN_PASSWORD

• Value: your actual password

  
  

🔹 API Token

• Name: API_TOKEN

• Value: your API key

  
  

👉 Click Add secret

Once added, secrets can be accessed inside your workflow YAML.

Example

env:
  LOGIN_USERNAME: ${{ secrets.LOGIN_USERNAME }}
  LOGIN_PASSWORD: ${{ secrets.LOGIN_PASSWORD }}
  API_TOKEN: ${{ secrets.API_TOKEN }}

👉 This makes the values available during test execution.

How to Access the Playwright Code

Inside your test or Page Object:

const username = process.env.LOGIN_USERNAME;
const password = process.env.LOGIN_PASSWORD;
const apiToken = process.env.API_TOKEN;

👉 Now your tests can use credentials securely.

The 3 Steps Required for Playwright in CI

According to Playwright official guidance, running tests in CI is simple and structured.

Every CI pipeline follows these 3 steps:

When running in CI, stability matters more than speed.

Playwright recommends:

👉 Run tests sequentially in CI

Now Let’s Build Our First CI Workflow (GitHub Actions)

Step 1: Create Workflow Folder

Inside your project:

.github/workflows/

Step 2: Create Workflow File

playwright.yml

Step 3: Add Basic CI Configuration

Now paste this:

name: Playwright Tests

on:

push:

branches: [ main, master ]

pull_request:

branches: [ main, master ]

jobs:

test:

timeout-minutes: 60

runs-on: ubuntu-latest

steps:

- name: Checkout Repository

uses: actions/checkout@v5

- name: Setup Node.js

uses: actions/setup-node@v6

with:

node-version: lts/*

- name: Install Dependencies

run: npm ci

- name: Install Playwright Browsers

run: npx playwright install --with-deps

- name: Run Playwright Tests

run: npx playwright test

- name: Upload Playwright Report

uses: actions/upload-artifact@v5

if: ${{ !cancelled() }}

with:

name: playwright-report

path: playwright-report/

retention-days: 30

Let’s Understand This Workflow

When will this run?

on:  push:  pull_request:

👉 Runs automatically when:

• Code is pushed

• PR is created

  
  

Where will it run?

runs-on: ubuntu-latest

👉 GitHub creates a Linux machine

What are the steps?

1. Checkout code

- uses: actions/checkout@v5

👉 Downloads your repo

2. Set up Node

- uses: actions/setup-node@v6

👉 Installs Node.js

3. Install dependencies

npm ci

4. Install browsers

npx playwright install --with-deps

5. Run tests

npx playwright test

6. Upload report

upload-artifact

👉 Stores HTML report inside GitHub

✔ The team can download it

✔ Useful for debugging

What Happens After You Push This?

Once you commit and push:

git add .
git commit -m "Added CI workflow"
git push

👉 GitHub will automatically:

✔ Detect workflow file

✔ Start pipeline

✔ Execute tests

✔ Generate report

Where to See Results?

Go to your repository:

👉 Click Actions tab

You will see:

✔ Workflow runs

✔ Status (Pass / Fail)

✔ Logs

✔ Artifacts (reports)

View the HTML Report

After the CI workflow finishes running, GitHub stores the Playwright HTML report as an artifact.

The HTML report helps us understand:

• Which tests passed

• Which tests failed

• Execution duration

• Error messages

• Screenshots (if configured)

• Trace links (if enabled)

Instead of opening the report locally, we download the generated report from GitHub.

Step-by-Step: Download Playwright HTML Report from GitHub Actions

Step 1: Open GitHub Repository

Go to your repository where the Playwright project is stored.

Example:

https://github.com/your-username/playwright-learn

Step 2: Click on the Actions tab

At the top of the repository page, click: Actions

This section shows all workflow runs triggered by:

• push

• pull request

• manual triggers

Step 3: Open the Latest Workflow Run

You will see a list of runs.

Click the latest workflow run.

Example:

Playwright Tests Commit message: Added CI workflow

Step 4: Check Job Status

Inside the workflow run, you will see:

test job → Completed

You can open logs for each step:

• Checkout repository

• Install dependencies

• Install browsers

• Run tests

• Upload artifact

If tests fail, logs help identify the reason.

Step 5: Locate Artifacts Section

Scroll to the bottom of the workflow run page.

You will see:

Artifacts

Example artifact:

playwright-report

Step 6: Download the Report

Click:

playwright-report.zip

GitHub will download a ZIP file containing the HTML report.

Step 7: Extract the ZIP File

After download:

Right-click → Extract All

Folder structure will look similar to:

playwright-report/index.htmldata/trace/assets/

Step 8: Open HTML Report

Inside extracted folder:

Double-click:

index.html

OR

Open terminal inside the folder:

npx playwright show-report

This opens the report in browser.

View Allure Report

Playwright HTML report is good, but Allure report provides a more advanced and visually structured dashboard. Visit for more details and basic concepts, and setup this post

Allure helps visualize:

• Test hierarchy

• Step details

• Attachments

• Screenshots

• Execution trends

• Categories of failures

Allure is commonly used in enterprise automation frameworks.

Pre-requisite

Allure requires Java (JDK).

Check Java:

java -version

If not installed:

Download JDK from:

https://adoptium.net/

Install with default settings.

Install Allure Command Line

Install globally:

npm install -g allure-commandline --save-dev

Verify installation:

allure --version

Ensure Playwright is Configured for Allure

Install Allure reporter:

npm install -D allure-playwright

Update playwright.config.ts:

reporter: [['list'],['html'],['allure-playwright']]

After running tests:

allure-results folder is created.

Step-by-Step: Download Allure Results from CI

Update workflow file to upload allure-results:

• name: Upload Allure Results

  
  

  uses: actions/upload-artifact@v5

  
  

  if: ${{ !cancelled() }}

  
  

  with:

  
  

  name: allure-results

  
  

  path: allure-results

  
  

  retention-days: 30

Push changes.

GitHub will now upload:

allure-results artifact.

Step-by-Step: Generate Allure Report Locally

Step 1: Download the allure-results artifact

From GitHub Actions:

Download:

allure-results.zip

Extract the folder.

Step 2: Generate Allure Report

Open terminal inside project folder.

Run:

allure generate ./allure-results --clean

Step 3: Open Allure Dashboard

Run:

allure open ./allure-report

Browser opens interactive dashboard.

View Playwright Trace

Trace is one of the most powerful debugging features in Playwright.

Trace allows you to:

Replay the test execution step-by-step.

It shows:

• Actions performed

• DOM snapshots

• Network calls

• Console logs

• Screenshots

• Element state

Trace helps identify:

Why the test failed, where the locator failed, and what the UI looked like at that moment

Step 1: Enable Trace in Playwright Config

Inside playwright.config.ts:

use: {trace: 'on-first-retry'}

Other options:

trace: 'on'

trace: 'retain-on-failure'

Recommended for CI:

trace: 'retain-on-failure'

Step 2: Run Tests in CI

Push changes.

CI workflow runs tests.

If any test fails:

trace.zip is generated.

Trace is stored inside:

test-results folder.

Step 3: Upload Trace Artifact in CI

Update workflow:

• name: Upload Test Results

  
  

  uses: actions/upload-artifact@v5

  
  

  if: ${{ !cancelled() }}

  
  

  with:

  
  

  name: test-results

  
  

  path: test-results

  
  

  retention-days: 30

Push changes.

GitHub stores trace files.

Step 4: Download Trace File

From GitHub Actions:

Download:

test-results.zip

Extract the folder.

Locate:

trace.zip

Step 5: Open Trace Viewer

Open terminal:

npx playwright show-trace trace.zip

Trace Viewer opens in the browser.