Forem: Nabin Ale

Playwright and GitHub Actions - Run tests in CI

Nabin Ale — Mon, 16 Mar 2026 08:49:26 +0000

This blog post explains how to run Playwright UI tests in CI (Continuous Integration) using GitHub Actions.
Before you start, you need to have a basic knowledge of GitHub Actions, Playwright, and the Playwright Trace Viewer to better understand this blog. If you are not familiar with any of these topics, below are links to our blogs that explain each one:

By the end of this blog, you will be able to set up a CI workflow that automatically runs your Playwright UI tests whenever you push code to your repository. You will also learn how to get Playwright trace reports when tests fail, making it easier to debug and fix errors.

🤔 Why run tests on CI?

Tests are run on CI to ensure the code works properly in a clean and isolated environment every time a change is made. Here are some reasons:

1. Early bug detection:
CI runs tests automatically on every push or PR, so you find problems right when they're introduced, not days or weeks later when the context is gone and fixes are harder.

2. No more "Works on my machine":
CI runs your tests in a clean environment every time. If tests pass there, it means your code works in a standard setup, not just on your own computer.

3. Protect the main branch:
Tests on CI act like a gatekeeper. If something breaks, it doesn't get merged. This keeps the main (or master) branch deployable and stable.

4. Confidence to refactor and move fast:
When tests run automatically, you can refactor aggressively. If CI is green, you didn't break existing behavior. That confidence significantly speeds things up.

5. Better collaboration:
CI gives everyone on the team the same test results. This helps avoid confusion and makes it clear whether the code is working or not.

6. Automated process:
CI systems enable developers to save time and effort on testing.

📘 About the Project

In this blog, I have taken a simple application with a frontend built using Vue.js and a backend built using json-server(a fake REST API). The GitHub repository is available at: https://github.com/nabim777/momo-restro-list.git

This is a basic application that includes login and logout functionality. E2E tests are written using Playwright to verify the login feature. You can find the test scenarios here

🛠️ Running App Locally

Before setting up CI, let's run the application and tests locally.

1. Install dependencies

npm ci

2. Start the frontend and backend servers

npm run serve              # Start frontend
npm run backend            # Start backend

🧪 Running UI Tests Locally

NOTE: Make sure both the frontend and backend are running before running the tests.

To run the UI tests locally, use the following command:

npx playwright install chromium
npm run test:e2e tests

⚙️ Setting Up CI in GitHub Actions

After verifying the app locally, the next step is to set up CI using GitHub Actions. First, create a file named ci.yml in your project using the following folder structure:

📦momo-restro-list
┗ 📂.github
┃ ┣ 📂workflows
┃ ┃ ┗ 📜ci.yml

Then, add the following code to the ci.yml file.

name: CI

on:
  push:
    branches:
      - master
  pull_request:
    branches:
      - master
  workflow_dispatch:

jobs:
  e2e-UI-tests:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repo code
        uses: actions/checkout@v6

      - name: Set up node
        uses: actions/setup-node@v6
        with:
          node-version: 24.x

      - name: Install dependencies
        run: |
          npm ci
          npx playwright install chromium

      - name: JS lint
        run: |
          npm run lint || (echo "Linting failed! Please run 'npm run lint:fix' to fix the errors." && exit 1)

      - name: Run the project
        run: |
          npm run serve &
          npm run backend &

      - name: Wait for services
        run: |
          sudo apt-get install wait-for-it -y
          wait-for-it -h localhost -p 8080 -t 10
          wait-for-it -h localhost -p 3000 -t 10

      - name: Run UI tests
        id: test-ui
        run: npm run test:e2e tests

      - name: Upload trace results
        if: ${{ failure() && steps.test-ui.conclusion == 'failure' }}
        uses: actions/upload-artifact@v6
        with:
          path: |
            trace-results/*.zip
            retention-days: 30

🔍 What does this workflow do?

This GitHub Actions file runs when you push to the master branch or create a pull request to master.

It has one job called e2e-UI-tests with these steps:

Checkout repo code - Gets the project code from GitHub.
Set up node - Installs Node.js version 24.
Install dependencies - Installs the project dependencies and Playwright browsers.
JS lint - Runs the linter to check for code quality issues. If linting fails, it will print a custom error message and exit with a failure status.
Run the project - Starts the Vue app and the backend using json-server.
Wait for services - Waits for the frontend (port 8080) and backend (port 3000) to be ready.
Run UI tests - Runs the UI tests using Playwright.
Upload trace results - If the UI tests fail, it uploads the Playwright trace results as an artifact that can be downloaded from the GitHub Actions interface. The trace files will be retained for 30 days.

📥 How to Download and View Trace Files?

If your tests fail in CI, you can download the trace files to see what went wrong:

Go to your GitHub repository
Click on the Actions tab
Select the failed workflow run
Scroll down to the Artifacts section at the bottom of the page
Click on the artifact name to download the trace files (they will be in a .zip file)
Extract the downloaded .zip file
Open the trace file using one of these methods:
- Drag and drop the trace file into trace.playwright.dev
- Or run this command locally: npx playwright show-trace path/to/trace.zip

The trace viewer will show you step-by-step what happened during the test, including screenshots, network requests, and console logs.

📝 Conclusion

Using GitHub Actions to run your Playwright tests means your app is tested automatically in a clean environment every time you make changes. It helps find bugs early, makes teamwork easier, and keeps your project stable.

CI tests turn "hope it works" into "we know it works."

Helpful for keycloak script

Nabin Ale — Fri, 23 Aug 2024 06:49:08 +0000

Altogether I have found three method to set up keycloak can be used as the bash script. methods are:

1. Using Admin CLI bash command
2. By importing the json file
3. Using API (recommended)

1. Using Admin CLI command

NOTE: following command is for docker if keycloak is locally run then you can run command inside ''

a. Login

docker exec keycloak-keycloak-1 /bin/bash -c 'cd opt/keycloak/bin && bash kcadm.sh config credentials --server <keycloak-host> --realm master --user admin --password admin'

b. Create realm

docker exec keycloak-keycloak-1 /bin/bash -c 'cd opt/keycloak/bin && bash kcadm.sh create realms -s realm=<realm-name> -s enabled=true -o'

c. Create clients( here we get client-id )

docker exec keycloak-keycloak-1 /bin/bash -c "cd opt/keycloak/bin && bash kcadm.sh create clients -r opendesk -s clientId=nextcloud -s enabled=true -s 'redirectUris=[\"<nextcloud-host>/apps/user_oidc/code\"]' -s rootUrl=<nextcloud-host> -s 'attributes.\"backchannel.logout.url\"=<nextcloud-host>/apps/user_oidc/backchannel-logout/Keycloak' -s 'attributes.\"post.logout.redirect.uris\"=<nextcloud-host>/*' -s 'webOrigins=[\"<nextcloud-host>\"]' -s adminUrl=<nextcloud-host>"

d. Get secretId

docker exec keycloak-keycloak-1 /bin/bash -c 'cd opt/keycloak/bin && bash kcadm.sh get clients/<Client-ID> -r <realm-name> --fields secret'

e. OIDC configure (this is for user_oidc on nextcloud)

docker exec --user www-data nextcloud php ./occ user_oidc:provider Keycloak --clientid="nextcloud" \
--clientsecret="<secret-id>" --discoveryuri="<keycloak-host>/realms/<realm-name>/.well-known/openid-configuration" --scope="openid email profile"

2. By importing the json file

It simply by importing the json file in a realm with the help of import admin bash cli command

bash kc.sh export --dir <path-to-json-file> --realm <realm-name>

3. Using API

a. getting the acess token using api

following curlcommand will store the acess_token in variable MASTER_TOKEN

MASTER_TOKEN=$(curl --location --request POST <keycloak-host>/realms/master/protocol/openid-connect/token \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'client_id=admin-cli' \
--data-urlencode 'username=admin' \
--data-urlencode 'password=admin' \
--data-urlencode 'grant_type=password' | jq -r '.access_token')

b. Creating the realm using API

curl --silent --show-error -L -X POST "<keycloak-host>/admin/realms" \
--header "Content-Type: application/json" \
--header "Authorization: Bearer ""$MASTER_TOKEN" \
--data '{"realm":"opendesk","enabled":true}'

c. Creating the clients using API

curl -X POST \
  "https://keycloak.local/admin/realms/opendesk/clients" \
  --header "Authorization: Bearer ""$MASTER_TOKEN" \
  --header "Content-Type: application/json" \
  --data '{
    "clientId": "nextcloud",
    "enabled": true, 
    "redirectUris" : ["<nextcloud-host>/apps/user_oidc/code"],
    "rootUrl": "<nextcloud-host>",
    "attributes": {
     "backUsing Admin CLI bash commandchannel.logout.url": "<nextcloud-host>/apps/user_oidc/backchannel-logout/Keycloak"
    }
  }'

d. Get the secret id using API

SECRET=$(curl -X GET \
  "<keycloak-host>/admin/realms/opendesk/clients" \
  --header "Authorization: Bearer ""$MASTER_TOKEN" | jq -r '.[] | select(.clientId == "nextcloud") | .secret')

Factory Design Pattern

Nabin Ale — Mon, 20 May 2024 01:23:39 +0000

The Factory Design Pattern is a way to create objects without specifying the exact class of the object that will be created. It provides a method to create objects that can be overridden by subclasses to change the type of objects that will be created.

Understanding through Example

Let's use the Factory Design Pattern with an example involving a waiter, a cook, and the client in a restaurant setting. Here’s how the pattern works in this context:

a. Waiter: Acts as the Factory.
b. Cook: Represents the different types of objects that can be created.
c. Client: Requests a dish through the waiter.

Scenario

A client goes to a restaurant and asks the waiter for a specific dish (e.g., Momo or Pizza). The waiter takes the order and instructs the cook to prepare the dish. The client doesn't know the details of how the dish is prepared; they just get the dish.

Step-by-Step Example in TypeScript

Step 1: Define the Dish Interface

interface Dish {
    prepare(): void;
}

This interface defines a method prepare() that every dish must implement.

Step 2: Create Concrete Classes for Dishes

class Momo implements Dish {
    prepare(): void {
        console.log("Preparing Momo");
    }
}

class Pizza implements Dish {
    prepare(): void {
        console.log("Preparing Pizza");
    }
}

These classes implement the Dish interface and provide their own version of the prepare method.

Step 3: Create the Waiter (Factory)

class Waiter {
    static orderDish(dishType: string): Dish | null {
        switch (dishType) {
            case 'Momo':
                return new Momo();
            case 'Pizza':
                return new Pizza();
            default:
                return null;
        }
    }
}

The Waiter class has a static method orderDish that takes a string parameter dishType and returns an instance of the corresponding dish.

Step 4: Client Requests a Dish

const dish1: Dish | null = Waiter.orderDish('Momo');
if (dish1) {
    dish1.prepare();  // Output: Preparing Momo
}

const dish2: Dish | null = Waiter.orderDish('Pizza');
if (dish2) {
    dish2.prepare();  // Output: Preparing Pizza
}

The client uses the Waiter to order dishes by specifying the dish type. The Waiter (factory) handles the creation of the dish, and the client receives a dish ready to be prepared.

Explanation

- Dish Interface: This defines a common interface that all dishes must follow.
- Concrete Classes (Momo, Pizza): Implement the Dish interface and provide specific implementations for the prepare method.
- Waiter (Factory): Contains the orderDish method, which decides which dish to create based on the given type.
- Client: Requests dishes from the Waiter without needing to know the details of how the dishes are created.

Full given Example in TypeScript look like this

// Dish Interface
interface Dish {
    prepare(): void;
}

// Concrete Momo Class
class Momo implements Dish {
    prepare(): void {
        console.log("Preparing Momo");
    }
}

// Concrete Pizza Class
class Pizza implements Dish {
    prepare(): void {
        console.log("Preparing Pizza");
    }
}

// Waiter (Factory) Class
class Waiter {
    static orderDish(dishType: string): Dish | null {
        switch (dishType) {
            case 'Momo':
                return new Momo();
            case 'Pizza':
                return new Pizza();
            default:
                return null;
        }
    }
}

// Client Code
const dish1: Dish | null = Waiter.orderDish('Momo');
if (dish1) {
    dish1.prepare();  // Output: Preparing Momo
}

const dish2: Dish | null = Waiter.orderDish('Pizza');
if (dish2) {
    dish2.prepare();  // Output: Preparing Pizza
}

To execute the code within a web browser click here

Why use the Factory Design Pattern?

1. Decoupling: It decouples the client code from the object creation process. It separates the part of the code that asks for an object from the part that makes the object. This way, the code that needs the object doesn't have to know exactly how the object is made
2. Flexibility: It allows the code to be more flexible and easier to extend. New classes can be added without changing the existing client code.
3. Single Responsibility: The Factory Design Pattern follows the Single Responsibility Principle by making sure that each class has only one job

Summary

In this example, the client interacts only with the Waiter (factory), asking for specific dishes. The Waiter then decides which type of dish to create and returns it to the client. This pattern decouples the client from the creation logic, making the system more modular and easier to maintain.

Introduction to GitHub Actions - CI & CD

Nabin Ale — Thu, 25 Apr 2024 05:06:24 +0000

GitHub Actions is an automation and CI/CD (Continuous Integration/Continuous Delivery or Deployment) service provided by GitHub, allowing us to automate our software development processes or workflows, from building and testing code to deploying it to different environments. It's an effective tool that can enhance software quality and save our time.

Some features of GitHub Actions:

It allows you to automate various stages of SDLC (Software Development Life Cycle), such as building, testing, deploying, and releasing software.
It simplifies CI/CD integration, facilitating seamless DevOps practices.

Components of GitHub Actions:

Workflows
Events
Jobs
Steps
Actions
Runners

1. Workflows

Workflows are automated procedures that you add to your repository. They will run when triggered by an event in your repository, or they can be triggered manually, or at a defined schedule. They can be used to build, test, package, release, or deploy a project on GitHub.

2. Events

Events are specific activities such as code push, pull request creation, issue creation, comments on pull requests or issues, etc., that trigger a workflow.

3. Jobs

Jobs are sets of steps that are executed in the same runner. A workflow with multiple jobs will run in parallel by default, but it can be configured so that jobs run sequentially.

4. Steps

A step is an individual task that can run the commands in a job. These can be actions or commands.

5. Actions

Actions are the standalone commands for the GitHub Actions platform that perform complex but frequently repeated tasks. Actions help to reduce repetitive code in workflows.

6. Runner

A runner is a GitHub Actions server where our workflows run. It listens for available jobs, runs multiple jobs at a time, and reports the progress, logs, and results back to GitHub. GitHub hosted runners are based on Ubuntu, Linux, Microsoft Windows, and Mac OS.

Note:
One event can trigger many workflows, a workflow can contain many jobs, and a job can contain many steps.

Process in GitHub Actions:

Getting started:

Before we dive into an example, make sure you have a repository where you want to set up your CI/CD workflow. If you don't have one, create a new repository, for example, named action-hero.

Step 1: Clone your repository into your system

git clone <your_github_repo_url>

Step 2: Go to path action-hero and create a folder named .github

cd action-hero
mkdir .github

Step 3: Go to path .github and create a folder named workflows

cd .github
mkdir workflows

Step 4: Inside the folder workflows, create a file named hello_world.yml

cd workflows
touch hello_world.yml

Our file structure should look like this:

📦action-hero
┗ 📂.github
┃ ┣ 📂workflows
┃ ┃ ┗ 📜hello_world.yml

Step 5: Add the following code snippet to your hello_world.yml file:

name: Hello world workflow

on:
  push:
    branches:
      - main

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
    - name: Checkout repository
      uses: actions/checkout@v2

    - name: Print a message
      run: echo "Hello, GitHub Actions!"

In this example:

The workflow is triggered by a push event on the main branch.
The job named "build" runs on the latest version of Ubuntu.
The first step checks out the repository using the actions/checkout action.
The second step simply prints a message using the echo command.

GitHub Actions activity:

The image above is the output from our GitHub Actions workflow run. It shows that the workflow was successful and completed the Hello world workflow job, which consisted of two steps: Checkout repository and Print a message.

The step Print a message executed the command echo "Hello, GitHub Actions!", resulting in the output Hello, GitHub Actions! being displayed in the workflow log.

Conclusion

In this blog, we've explored GitHub Actions, an automation and CI/CD service provided by GitHub. We've learned about its key components and how they work together to automate software development workflows.

GitHub Actions enables us to automate tasks like building, testing, and deploying code, leading to improved software quality and time savings.

With a practical example, we've seen how easy it is to set up a basic workflow.

In summary, GitHub Actions is a powerful tool for speedy development processes, making it easier to deliver high-quality software efficiently.

Set SSH keys for Github in ubuntu or linux mint

Nabin Ale — Sat, 14 Oct 2023 01:50:52 +0000

Github Installation

sudo apt install ppa-purge
sudo ppa-purge ppa:git-core/ppa
sudo apt purge git

Configuring the git

git config --global user.name "<your_github_username>"
git config --global user.email <your_email@example.com>

NOTE: To check the user.name and user.email set or not
git config -l

Keys generation

Step 1: Generate new ssh keys

ssh-keygen -t ed25519 -C "your_email@example.com"

Step 2: Add a new ssh keys

cat ~/.ssh/id_ed25519.pub

Output will be something like this

ssh-ed25519
NAAAC3Nza*********jPRyyNVIdgj
your_email@example.com

Step 3: Copy output and paste in setting > SSH and GPG keys > new SSH key