How to test API load with k6 using GitHub Actions -

Table of contents

Reading Time: 5 minutes

Hi friends,

As we are all familiar with CI/CD and it has taken a very crucial place in the software development industry. Along with our development code therefore it is very important to integrate our automated tests with CI/CD as well. But you may think that we already have Jenkins and other CICD tools available in the market so why do we use GITHUB action in place of others But the Github actions tool has its own advantages, we’ll explore it later. Hence, this blog aims to throw some insights on integrating our k6 tests with Github action. So, let’s get started first.

📖What you will learn

Github Action

GitHub Actions is a continuous integration and continuous delivery (CI/CD) platform that allows you to automate your build, test, and deployment pipeline therefore you can create workflows that build and test every pull request to your repository or deploy merged pull requests to production.

Key features

Not required any setup configration.
It does not required to download and install any Plugin – like jenkins.
GitHub provides Linux, Windows, and macOS virtual machines to run your workflows –
You can host your own self-hosted runners in your own data center or cloud infrastructure.

The above fundamental features make GitHub’s actions more powerful and most effortless CICD tools among which we have earlier tools like Jenkins, etc.

integrate k6 with GitHub action

Basically, To integrate k6 with GitHub action we need k6 based test script, therefore we take a simple GET/POST request with some load setup in our example.


// Load test setup
export let options = {
  thresholds: {
    "http_req_duration": ["p(95)<1000"]
   },
  stages: [
      { duration: '5s', target: 50 }, // simulate ramp-up of traffic from 1 to 50 users over 5 seconds.
      { duration: '10s', target: 50 }, // stay at 50 users for 10 seconds.
      { duration: '5s', target: 0 }, // ramp-down to 0 user in last 5 seconds.
  ]
};
export default function () {
  let res = http.get('https://reqres.in/api/users?page=2');
  console.log(res.status)
  check(res, {
    'is status 200': (r) => r.status === 200
  });

Setting up the GitHub Actions workflow

Before setting up the workflow, we need to push the k6 script-based code to GitHub and once the code is on GitHub then we are ready to integrate with GitHub Action. we need to create a workflow configuration and place it in .github/workflows. So let’s start configuring the .yml file in the following steps.

Step 1:

Basically, in this step, we declare a name of the workflow, and along with the name we also define and declare the condition related to when workflow run automatically. for better understanding let`s take an example

# This is a basic workflow to help you get started with Actions

name: k6 Load Test

# Controls when the workflow will run
on:
  # Triggers the workflow on push or pull request events but only for the main branch
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

Step 2:

In this step Basically, we define jobs related to our code, and along with the job, we also define the virtual OS(window, ubuntu, iOS) for job runners to move forward and take an example for better understanding.


  # Allows you to run this workflow manually from the Actions tab
  workflow_dispatch:

# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
  # This workflow contains a single job called "job_1"
  job_1:
    # The type of runner that the job will run on
    runs-on: ubuntu-latest

Step 3:

In this step, we define an important concept of checkout action inside the job. Basically, these steps checkout your repository under the GitHub workspace so job runners access it.

 # Steps represent a sequence of tasks that will be executed as part of the job
    steps:
      # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
      - uses: actions/checkout@v2

      # Runs a single command using the runners shell
      # optional step
      - name: Run a one-line script
        run: echo Hello, world!

Step 4:

Step 4 is the main and final step that connects GitHub action to k6, Basically in this step, we define an action that loads k6 in our runner and now the job runner is ready for execution once we define the file name.

 # set up k6
      - name: Run local k6 test
        uses: k6io/action@v0.1
        with:
         filename: first.js

.yml file exection

Basically .yml contains multiple jobs based on our requirements and according to the above condition, the .yml file starts execution whatever the new code is pushed or pulled in the repository.

End-of-test summary report

At the end of the test, the summary is shown at every execution but when we need a standard summary and an Html based report is generated as the end summary. then we add one or two-line codes into our k6 code file. But before that, we need to import a library into our code.

import { htmlReport } from "https://raw.githubusercontent.com/benc-uk/k6-reporter/main/dist/bundle.js";

export function handleSummary(data) {
  return {
    "new2.html": htmlReport(data), // show report in html based format.
    'stdout': textSummary(data, { indent: ' ', enableColors: true }), // Show the text summary to stdout format...
  };
}

It is a standard-based format of end-to-end summary-based report it generates at the end job in the terminal.

At the end of this blog, I define optional steps which is not important as much above step but once you understand and add this step into our job or workflow then this step is beneficial for reporting or end to end summary purpose, so now move forward towards this step and understand the concept of Artifact in GitHub action.

Step 5:

what are Artifacts?

Artifacts allow you to share data between jobs in a workflow and store data once that workflow has been completed.

Html based is also an end-to-end summary-based report and users can get a better understanding from it but it is only available when using artifact concept into our workflow so, let’s started with an example.

      - name: Upload html report for job 1
        uses: actions/upload-artifact@v2
        with:
          #html file name define in k6 code
          name: summary  
          # path in our github repo
          path: summary.html  
          # available time period file after that is automatically remove from the workspace 
          retention-days: 2