Unleash test pipelines in your delivery workflow(s)

#testing #delivery #pipelines

If you run a separate repository for your test projects or you have tests or other projects unrelated to your main app in your code base or you simply just want to know some more on how to setup a test pipeline for your projects on Gitlab or any related CD platform. We’ve put together this article for you; a view study of how we do it at GotPhoto**

Often than not you’d have any of the cases above where you’d want a
modular test suite that’s accessible from different teams across your
CI tool. In this article, I’ll go through some familiar steps that
goes beyond having test schedules and pipeline jobs; being two of the
most common ways to test in a deployment process.

I’ll be using Gitlab as a main example but the approach here goes along with pretty much any .yml supported workflow and any version control system, in a web, javascript, cloud based setup.

Let’s start by setting goals

Enable access to tests from a requesting project to a source project
Report all test status via Slack
Report visual test results

We’ll focus on the first 2 goals here and finish the 3rd in another “ticket”.

Goal 1: Enable access to tests from a requesting project to a source project

Let’s assume your have 2 teams, primarily your source and target teams and Team “Testars” manage your test code while Team “Pigeons” manage other application code.

In Team “Testars”: ideally your tests can be triggered via commands which may or not contain required values in your pipeline environment to execute. Your workflow may be similar to: Test code is available on a folder in your project, your project contains necessary packages to install and run all tests and its dependencies in your CI, your test are triggered with commands and result is a status output in your deployment tree.

Now let’s bring in the Team “Pigeons”, with a different code base in your VCS, you can leverage the multi-project pipeline trigger. The idea is pretty simple, Pigeons implement a delivery workflow that includes a test stage, this then invokes tests in your Team Testars project and makes results available to Team Pigeon.

Here’s an illustration of what your project may look like:

pigeonsPipeline.yml

test:
variables:
ENVIRONMENT: staging
REQUESTING_TEAM: Pigeons
TEST_COMMAND: npx...
stage: deploy
trigger: <test_project_repository_here>

testarsPipeline.yml

.job_template:
image:
stage: test
only:
refs:
- master
- pipelines
script:
- $(npm bin)/${TEST_COMMAND}
- bash ./notify.sh "$ENVIRONMENT" "$REQUESTING_TEAM" "$TEST_COMMAND"

A few things to note here:

testarsPipeline requires a custom command, this allows you truly open up your tests as different teams may have different commands depending on their workflow
testarsPipeline also opens up test trigger sources to the “pipelines” tag. This ensures the test pipeline runs when triggered via a pipeline process.
pigeonsPipeline is invoking tests by providing environment variable in the stage which is passed on to the triggered test project.

And there you have it, Bob’s your uncle? Not yet.

Goal 2: Report all test status via Slack

Test triggers in this workflow will eventually have a wider range of subscribers, this is good but you’d want to keep an eye on the activity, especially when working in a cross functional team. Slack allows you setup incoming webhooks for purposes like this. You can add a step to your test pipeline that sends a message to a predefined Slack channel, letting you and your team know when a test pipeline has been triggered, by who and whatever else information you gather and require on the go.

Lets write it…

Setup a Slack app and provision its support for incoming webhooks
Create a Slack channel to report to
Create a webhook for your Slack channel
Write a bash script to send your notifications

To setup a Slack app, the steps are quite straight forward using the Slack API UI on Slack API Documentation and same case for setting up a new Slack Channel or you may want to reuse an existing one. Creating an incoming webhook can also be done via the Slack API and all you’d need is your Webhook URL address, this looks something like

https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXX

Now you’ll need to setup a bash script to fulfil the last line of your testarsPipeline file. Remember we now have access to 3 environment variables provided via Pigeons, this will be passed to a custom shell script via the testarsPipeline, then we’d make a simple or formatted payload containing your variables and any other data you’ve added and finally make a curl request.

notify.sh

#!/bin/bash
SLACK_PAY_LOAD="
{
    'text': '$REQUESTING_TEAM triggered $TEST_COMMAND on $ENVIRONMENT environment'
}
"
curl -X POST -H 'Content-type: application/json' --data "${SLACK_PAY_LOAD}" https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXX

A few things to note in the notify.sh file:

To access your variables, you’d need to use single quotes, there might be cases where this breaks your payload if you have quotes in your variables. I recommend concatenation here.
You should consider masking your payload URL as well as other improvements you find useful.

Have an idea on what to do with step 3? We are consideering building an API enabled dashboard using the Cypress test events.

If you found this interesting, you'd love working with us at GotPhoto
where you have the opportunity to build with an amazing team. Consider
joining us at GotPhoto