vibssingh

Run Gradle API Tests in GitLab CI/CD

Last Updated On

HOME

This tutorial explains the process to run the Gradle API Tests in the GitLab pipeline. This is a very important step towards achieving CI/CD.

Table Of Contents

  1. Prerequisite
  2. What is GitLab CI/CD Workflow?
  3. GitLab Section
    1. Create a blank project in GitLab
    2. Push the project from the local repository to Gitlab Repository
    3. Create a .gitlab-ci.yml file in the project in GitLab
    4. View GitLab Pipeline
    5. Run the tests in the GitLab pipeline
    6. Check the status of the pipeline
    7. Download the report

Prerequisite:

  1. Serenity – 2.6.0
  2. Serenity Cucumber – 2.6.0
  3. Serenity Rest Assured – 2.6.0
  4. Rest Assured – 4.3.2
  5. Java 11
  6. JUnit – 4.13.2
  7. Gradle – 7.2
  8. GitLab Account

Please refer to this tutorial to get the structure and code of the Gradle project with Serenity and Rest API – Serenity BDD with Cucumber and Rest Assured in Gradle

What is GitLab CI/CD Workflow?

GitLab automatically enables CI/CD pipelines for new projects. It’s just a matter of adding a new configuration file called .gitlab-ci.yml to your code repository with instructions for GitLab on what to run. So simply create the following basic workflow in your main repository directory and commit it.

GitLab Section

Step 1 – Create a blank project in GitLab

To know, how to create a blank new project in GitLab, please refer to How to create a new project in GitLab.

Step 2 – Push the project from the local repository to Gitlab Repository

To know, how to push the changes to GitLab, please refer to How to push new local GIT Repository to GitLab.

Step 3 – Create a .gitlab-ci.yml file in the project in GitLab

There are many ways to create a new file in GitLab. One of the ways is to create a file as shown in the below image.

It is a YAML file where you configure specific instructions for GitLab CI/CD. In the .gitlab-ci.yml, we can define:

  • The scripts you want to run.
  • Other configuration files and templates you want to include.
  • Dependencies and caches.
  • The commands you want to run in sequence and those you want to run in parallel.
  • The location to deploy your application to.
  • Whether you want to run the scripts automatically or trigger any of them manually.

Below is a sample example to run the Gradle tests in the GitLab pipeline.

image : gradle:7.1.0-jdk11 
stages:
  - test

variables:
  GRADLE_OPTS: "-Dorg.gradle.daemon=false"

test:
  stage: test
  allow_failure: true
 
# Run the tests
  script:
    - echo "Executing BDD scenarios with Gradle"
    - gradle clean test
    - gradle reports	

 
# Store artifacts
  artifacts:
    when: always
    name: "Gradle Report"
    paths:
    - lib/target/site/serenity/*
    expire_in: 24 h

Image – gradle:7.1.0-jdk11 is used in this test. It is a docker image for Gradle with Java 11 installed in it.

Pipeline configuration begins with jobs. Jobs are the most fundamental element of a  .gitlab-ci.yml file.

Jobs are:

  • Defined with constraints stating under what conditions they should be executed.
  • Top-level elements with an arbitrary name and must contain at least the script clause.
  • Not limited in how many can be defined.

Jobs can output an archive of files and directories. This output is known as a job artifact. The expire_in keyword determines how long GitLab keeps the job artifacts. Here, it shows 24 hrs to retain the artifacts.

Step 4 – View GitLab Pipeline

Now, when a new change is committed, a pipeline kicks off and it runs all the tests. To view the pipeline, go to the left panel and click on the Build option. There are a number of sub-options in the Build option, click on the Pipelines.

Step 5 – Run the tests in the GitLab pipeline

The below image shows that the tests are running in the GitLab pipeline.

Step 6 – Check the status of the pipeline

Once the Status of the pipeline changes to either failed or passed, that means the tests are already executed.

As you can see, the Status is passed, its green colour. This means all the tests present in the test suite are executed and passed. If any test fails in the test suite, the final execution status will be brown. The reason for the brown colour is we have mentioned allow_failure: true.

Below shows the execution status report in the GitLab pipeline.

As I have added an artifact also in the .gitalb-ci.yml, which is highlighted in the image. This artifact creates a folder with the name “Serenity_Report” and the reports in this folder come from the path /target/site. This artifact gives us the option to download the reports or browse the report. This report will be available for 24 hours only as mentioned in the gitlab-ci.yml.

Step 7 – Download the report

Once, will click on the download button, it will download “Gradle_Report.zip”. Unzip the folder and it looks like something as shown below:

Example of Index.html

Example of Serenity Summary Report

Congratulations. This tutorial has explained the steps to run Serenity tests in GitLab CI/CD. Happy Learning!!

Posted in GitLabTagged , , , , , , Leave a comment

Leave a comment