Within this tutorial I will explain shortly the combination of GitLab and Sitespeed.io. Normally GitLab provides this feature (Browser Performance Testing) but only with Premium or Silver editions. I imagine for this example that you know already the basics about GitLab pipelines, Docker in Docker and Sitespeed.io.
Preparation
As a first step you create a simple project directory with some files and one folder.
# create project directory
$ mkdir -p ~/Projects/SitespeedGitLab/ci
# change directory
cd ~/Projects/SitespeedGitLab
# create login file
$ vim ci/login.js
# create urls file
$ vim ci/urls.txt
# create pipeline file
$ vim .gitlab-ci.yml
# show structure (optional)
$ tree .
.
|__.gitlab-ci.yml
|__ci
|__login.js
|__urls.txt
Content of files
For the login we use the simplest version of a script which serves as pre script. You can expand it later as needed. If you do not need a login, you do not have to create this file (leave this out later in the command --preScript login.js
).
module.exports = async function(context, commands) {
// navigate to login page
await commands.navigate('your domain');
// add values into input fields
await commands.addText.byId('username', 'input by id');
await commands.addText.byId('password', 'input by id');
// find the submit button and click it
await commands.click.byClassName('Button');
// wait to verify that you are logged in (incl. max time)
return commands.wait.byId('specific tag with id',8000);
};
Let’s get to the next file. Here you simply enter all URLs to be checked. Each line represents a URL to be checked which (in our case) always precedes the login. There is also the possibility to login once for all sub-pages as well as various actions on the pages. In this case you would have to script everything (similar to pre/post scripts).
your url one
your url two
your url three
The files urls.txt and login.js have to be mounted inside the container. Therefore we choose the folder “ci”. After the successfully execution this folder will also provide the sitespeed reports.
Pipeline
The last step is the definition of GitLab pipeline. Here now a very simple example for .gitlab-ci.yml, with only one pipeline stage (test) and job (perf_tests). You can also expand this file later as you like (It’s already possible to build Docker images inside).
stages:
- test
variables:
DOCKER_HOST: tcp://localhost:2375/
DOCKER_DRIVER: overlay2
DOCKER_TLS_CERTDIR: ""
default:
image: docker:stable
services:
- name: docker:dind
perf_tests:
stage: test
variables:
MOUNT_PATH: "$CI_BUILDS_DIR/ci/"
DOCKER_IMAGE: 'sitespeedio/sitespeed.io'
BROWSER: 'firefox'
ITERATION: '1'
artifacts:
name: "performance-reports"
paths:
- "$CI_BUILDS_DIR/ci/sitespeed-result/your domain"
script:
- docker run --shm-size=1g --rm -v $MOUNT_PATH:/sitespeed.io $DOCKER_IMAGE -b $BROWSER -n $ITERATION --preScript login.js urls.txt
Okay … done. You can commit/push everything into GitLab. After successfully pipeline run you can access the reports as GitLab pipeline artifacts (but not via repository folder -> because if the job is done the container and reports are gone).