Running Artillery on GitHub Actions
What you'll learn
- How to set up a GitHub Actions workflow to run your Artillery tests
- How to schedule your Artillery tests to run at a specific time
Overview
Integrating Artillery with GitHub Actions allows you to track your service's performance while developing your applications in your existing GitHub repositories. The following guide will show you how to load-test your services using a GitHub Actions workflow.
You can find the complete source code used in this guide in the Artillery CI/CD Examples GitHub repo (opens in a new tab).
Artillery test script example
In this guide, we'll use the following Artillery test script to run a load test on a running Socket.IO service, sending 50 virtual users per second for 10 minutes and ensuring the aggregate maximum latency for the test is under 500 milliseconds:
config:
target: "http://lab.artillery.io"
phases:
- duration: 600
arrivalRate: 50
ensure:
maxErrorRate: 1
max: 500
scenarios:
- name: "Emit an event"
engine: "socketio"
flow:
- emit:
channel: "echo"
data: "Hello from Artillery"
response:
channel: "echoResponse"
data: "Hello from Artillery"
You can run an example of this test script and see it in action. (opens in a new tab)
Setting up a GitHub Actions workflow
GitHub looks for configuration files placed inside your code repository in a directory called .github/workflows
. The configuration files use YAML syntax to define the events that will trigger your workflow and the jobs and steps to execute.
For this guide, the Artillery load test for the Socket.IO service will run after pushing new code to the main
branch of your GitHub repository. We'll also use the official Artillery GitHub Action (opens in a new tab) to execute the load test.
Create a GitHub Actions workflow configuration file placed in .github/workflows/load-test.yml
with the following contents:
name: Artillery Socket.IO Load Test
on:
push:
branches:
- main
jobs:
artillery:
runs-on: ubuntu-latest
steps:
- name: Checkout repository
uses: actions/checkout@v2
- name: Execute load tests
uses: artilleryio/action-cli@v1
with:
command: run tests/performance/socket-io.yml
Commit this file to the main
branch of your repository. Once you push the update to GitHub, GitHub Actions will execute the load test:

Scheduling Artillery load tests
You can also schedule GitHub Actions to run a workflow on a recurring schedule using the on.schedule
configuration setting, which is helpful if you want to execute your Artillery load tests at a specific time. For instance, you may wish to load-test your production applications outside of peak hours.
The on.schedule
setting accepts a string using the POSIX cron syntax (opens in a new tab), with the times in UTC. The following configuration will automatically trigger the GitHub Actions workflow every day at midnight UTC:
name: Artillery Socket.IO Load Test
on:
push:
branches:
- main
schedule:
- cron: "0 0 * * *"
jobs:
artillery:
runs-on: ubuntu-latest
steps:
- name: Checkout repository
uses: actions/checkout@v2
- name: Make reports directory
run: mkdir reports
- name: Execute load tests
uses: artilleryio/action-cli@v1
with:
command: run tests/performance/socket-io.yml --output reports/report.json
Distributed load testing on GitHub Actions
You can scale your load tests by using Artillery's support for AWS Lambda and AWS Fargate to execute your tests from different geographic regions within your AWS infrastructure.
To trigger distributed Artillery tests from GitHub Actions workflows, you'll need to set up AWS IAM permissions to allow the workflow to access AWS resources.
The following configuration will execute your Artillery test script in the us-east-1
region using the AWS_ACCESS_KEY_ID
and AWS_SECRET_ACCESS_KEY
values set as encrypted secrets:
name: Artillery Socket.IO Load Test
on:
push:
branches:
- main
schedule:
- cron: "0 0 * * *"
jobs:
artillery:
runs-on: ubuntu-latest
steps:
- name: Checkout repository
uses: actions/checkout@v2
- name: Execute load tests on AWS (us-east-1 region)
uses: artilleryio/action-cli@v1
with:
command: run-fargate --region us-east-1 --count 5 my-test.yml
env:
AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}