devops

vibssingh

How to run scheduled jobs using GitLab CI/CD

Last Updated On

HOME

This tutorial explains the process to schedule the run of 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. Schedule the pipeline
    5. Verify that the job is scheduled
    6. Run the tests in the GitLab pipeline
    7. Check the status of the pipeline
    8. Download the report
  4. How to schedule a cron job?

Prerequisite:

  1. GitLab Account

Please refer to this tutorial to get the structure and code of the SpringBoot project – Testing of SpringBoot Application with JUnit5

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:

By default, GitLab will have CI/CD pipelines and Auto DevOps enabled for all projects. What this means is that, when you push code to the repository, GitLab will automatically trigger the pipeline.

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. I have already created a .gitlab-ci.yml in the project, which can be seen in the 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 SpringBoot project (Maven) in the GitLab pipeline.

image: maven:3.8.5-openjdk-17
 
stages:
  - test
 
variables:
  MAVEN_OPTS: "-Dmaven.repo.local=.m2/repository"
 
test:
  stage: test
  allow_failure: true
 
# Run the tests
  script:
    - echo "Executing SpringBoot scenarios with maven"
    - mvn clean test site
 
# Store artifacts
  artifacts:
    when: always
    name: "SpringBoot Report"
    paths:
    - target/site/*
    expire_in: 24 h

Image – maven:3.8.5-openjdk-17 is used in this test. It is a docker image for Maven and has Java 17 installed in it.

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

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 – Schedule the pipeline

To schedule the pipeline, go to the left panel and click on the Build option. There are several sub-options in the Build option, click on the Pipeline Schedules.

Click on the button “New Schedule” to create a schedule for the pipeline.

To add a pipeline schedule, we need to fill in the details displayed on this page.

  1. Description – Provide the description of the project
  2. Interval Pattern – Select one of the preconfigured intervals, or enter a custom interval in cron notation. Here, I have used 30 16 * * *, which means the job is scheduled to run every day at 4:30 PM.
  3. Cron TimeZone – Mention the timezone in which the job should run. Here, I have used [UTC+1]Dublin timezone.
  4. Target branch or tag – Select the branch or tag for the pipeline. Here, I have selected the “main” branch.

Click on the “Save pipeline schedule”.

Step 5 – Verify that the job is scheduled

Below is the image of the newly created pipeline. This shows all the necessary details like description, target, last pipeline, next run, and owner.

The “Next Run” shows the expected time to run the pipeline. Here, it shows that the run is going to start.

This image shows that the run has started, and it is in a pending state right now.

Step 6 – Run the tests in the GitLab pipeline

The pipeline runs automatically as per the time specified in the “Interval Pattern”. The below image shows that the tests are running in the GitLab pipeline.

Step 7 – 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 is the execution status report in the GitLab pipeline.

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 “SpringBoot_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 8 – Download the report

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

Example of SureFire-Report.html

Example of Project Summary Report

How to schedule a cron job?

Five fields that are separated by whitespace make up a scheduling item. By adding more than one entry, you can schedule a job for more than one time.

MinuteHourDay of MonthMonthDay of week

MINUTE (0-59), HOUR (0-23), DAY (1-31), MONTH (1-12), DAY OF THE WEEK (0-6)

Each field can contain an exact value or use a set of special expressions:

  • The asterisk * indicates all valid values. So, a job that runs every day has a * in the third field.
  • A dash separates ranges of values. For example, a job that runs every hour from 9:00 a.m. to 5:00 p.m. would have 9-17 in the second field.
  • Intervals are specified with a slash /. A job that runs every 15 minutes has H/15 in the first field. Note that the H in the first field has a special meaning. If you wanted a job to run every 15 minutes, you could configure it as 0/15, which would make it run at the start of every hour.
  • Finally, you can specify multiple values with a comma. So, a job that runs Monday, Wednesday, and Friday would have 1,3,5 in the fifth field.

Here are several special predefined values that can be used to substitute the expressions in the cron.

EntryDescriptionDescription
@yearlyRun at any time during the yearH H H H *
@annuallyRun at any time during the yearH H H H *
@monthlyRun at any time during the monthH H H * *
@weeklyRun at any time during the weekH H * * H
@dailyRun at any time during the dayH H * * *
@hourlyRun at any time during the hourH * * * *

Here are the most common examples of cron job schedules that can be found in almost any crontab on Linux :

ScheduleJob
* * * * *Run cron job every minute
H/5 * * * *Run cron job every 5 minutes
H/30 * * * *Run cron job every 30 minutes
0 * * * *Run cron job every hour
0 H/3 * * *Run cron job every 3 hours
0 13 * * *Run cron job every day at 1pm
30 2 * * *Run cron job every day at 2:30 am
0 0 * * *Run cron job every day at midnight
0 0 * * 0Run cron job every Sunday
0 0 * * 1Run cron job every Monday
0 0 1 * *Run cron job every first day of every month
0 0 1 1 *Run cron job every first of January every year

Congratulations. This tutorial has explained the steps to schedule the pipeline in GitLab CI/CD. Happy Learning!!

vibssingh

How to Schedule a Jenkins Job

Last Updated On

HOME

In this post, we’ll show you how to schedule Jenkins jobs, and we’ll review some specific scenarios.

Table of Contents

  1. Jenkins Job Scheduling Syntax
  2. Add a Schedule to a Jenkins Job
    1. Create a new project using the Maven project plugin
    2. Go to the Build section of the new job
    3. Go to the Build Triggers
    4. Verify the Build History

Jenkins Job Scheduling Syntax

Let’s first have a look at the Jenkins task scheduling setup. You don’t need to be familiar with Linux’s command line environment to understand it, but it resembles the cron syntax quite a bit.

Five fields that are separated by whitespace make up a scheduling item. By adding more than one entry, you can schedule a job for more than one time.

Minute Hour Day of Month Month Day of week

MINUTE (0-59), HOUR (0-23), DAY (1-31), MONTH (1-12), DAY OF THE WEEK (0-6)

Each field can contain an exact value or use a set of special expressions:

  • The asterisk * indicates all valid values. So, a job that runs every day has a * in the third field.

  • A dash separates ranges of values. For example, a job that runs every hour from 9:00 a.m. to 5:00 p.m. would have 9-17 in the second field.

  • Intervals are specified with a slash /. A job that runs every 15 minutes has H/15 in the first field. Note that the H in the first field has a special meaning. If you wanted a job to run every 15 minutes, you could configure it as 0/15, which would make it run at the start of every hour. However, if you configure too many jobs this way, you can overload your Jenkins controller. Ultimately, the H tells Jenkins to pick a minute based on a hash of the job name. 

  • Finally, you can specify multiple values with a comma. So, a job that runs Monday, Wednesday, and Friday would have 1,3,5 in the fifth field.

Here are the several special predefined values that can be used to substitute the expressions in Jenkins cron.

Entry Description Description
@yearly Run at any time during the year H H H H *
@annually Run at any time during the year H H H H *
@monthly Run at any time during the month H H H * *
@weekly Run at any time during the week H H * * H
@daily Run at any time during the day H H * * *
@hourly Run at any time during the hour H * * * *

Here are the most common examples of cron job schedules that can be found in almost any crontab on Linux (use H in the examples below to spread the load evenly in Jenkins):

Schedule Job
* * * * * Run cron job every minute
H/5 * * * * Run cron job every 5 minutes
H/30 * * * * Run cron job every 30 minutes
0 * * * * Run cron job every hour
0 H/3 * * * Run cron job every 3 hours
0 13 * * * Run cron job every day at 1pm
30 2 * * * Run cron job every day at 2:30 am
0 0 * * * Run cron job every day at midnight
0 0 * * 0 Run cron job every Sunday
0 0 * * 1 Run cron job every Monday
0 0 1 * * Run cron job every first day of every month
0 0 1 1 * Run cron job every first of January every year

Add a Schedule to a Jenkins Job

Step 1: Create a new project using the Maven project plugin

In the General section, enter the project description in the Description box.

Step 2: Go to the Build section of the new job

  • In the Root POM textbox, enter the full path to pom.xml
  • In the Goals and options section, enter “clean test”

Click on the Apply and Save buttons.

Step 3: Go to the Build Triggers

Select the Build periodically option and mention the schedule.

This will open the scheduling text area.

H/5 * * * *

This schedule means that the job will run every 5 minutes.

Click on the Apply and Save buttons.

Step 4: Verify the Build History

Here is a screenshot of a couple of builds on our system. The timestamps show that you’ve scheduled a job to run every five minutes.

Below is the Build History.

In this post, we covered Jenkin’s job scheduling abilities, and we covered how to configure jobs for different intervals. 

vibssingh

How to use the JMeter Maven Plugin

Last Modified Date

HOME

In this tutorial, we will integrate JMeter with Maven to support CI/CD.

Maven and jmeter-maven-plugin make it easy to integrate performance tests with CI/CD tools & technologies such as Jenkins/Jenkinsfiles or Azure/Azure pipelines and cloud build agents. It also helps to run your tests with different versions of JMeter.

Table of Contents

  1. What is JMeter Maven Plugin
  2. How to use the JMeter Maven Plugin
    1. Create a new Maven Project
    2. Compile the new project
    3. Add Maven Compiler Plugin
    4. Add JMeter Maven Plugin
    5. Create a new directory src/test/jmeter and place JMeter Script in it
    6. Run JMeter Test with JMeter Maven Plugin
  3. Create a Test Plan in JMeter
    1. Add Thread Group
    2. Adding JMeter elements
    3. Adding Listeners to Test Plan
    4. Save the Test Plan

What is JMeter Maven Plugin

This is a Maven 3 plugin that allows you to run JMeter tests as part of the build.

How to use the JMeter Maven Plugin

Step 1 – Create a new Maven Project

A new project will be created with pom.xml as shown below

pom.xml is our Maven project main file, which contains all the necessary information and dependencies bound to our project.

Step 2 – Compile the new project

Compile the project by using the below command

mvn clean compile

The compilation fails with the errors as shown below:

Step 3 – Add Maven Compiler Plugin

Add the Maven Compiler plugin in the build section of the pom.xml.

<build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>3.11.0</version>
        <configuration>
          <source>11</source>
          <target>11</target>
        </configuration>
      </plugin>
    </plugins>
  </build>

Rerun compile command and this time the build is successful.

Step 4 – Add JMeter Maven Plugin

Add the JMeter Maven plugin to the build section of the pom.xml.

<plugin>
                <groupId>com.lazerycode.jmeter</groupId>
                <artifactId>jmeter-maven-plugin</artifactId>
                <version>3.6.0</version>
                <executions>
                    <!-- Generate JMeter configuration -->
                    <execution>
                        <id>configuration</id>
                        <goals>
                            <goal>configure</goal>
                        </goals>
                    </execution>
                    <!-- Run JMeter tests -->
                    <execution>
                        <id>jmeter-tests</id>
                        <goals>
                            <goal>jmeter</goal>
                        </goals>
                    </execution>
                    <!-- Fail build on errors in test -->
                    <execution>
                        <id>jmeter-check-results</id>
                        <goals>
                            <goal>results</goal>
                        </goals>
                    </execution>
                </executions>
                <configuration>
                    <generateReports>true</generateReports>
                </configuration>
            </plugin>

Step 5 – Create a new directory src/test/jmeter and place JMeter Script in it

Create a new directory within src/test with the name jmeter.

Place the JMeter script(.jmx) file in src/test/jmeter. The steps to create a Test Plan in JMeter are mentioned at the end of the page.

Step 6 – Run JMeter Test with JMeter Maven Plugin

Go to your project directory and run the following command in the command line:

mvn clean verify

The test execution is displayed in the command line as shown below:

The test ran successfully! The results are located at /target/jmeter/reports. You will find an HTML report named “Index.html”:

Right-click on the Index.html and select Open In->Browser->Chrome (any browser of your wish).

This report provides the following metrics:

In the Dashboard of the report;

  • APDEX (Application Performance Index) table that computes for every transaction the APDEX based on configurable values for tolerated and satisfied thresholds
  • A request summary graph showing the Success and failed requests

A Statistics table providing in one table a summary of all metrics per transaction including 3 configurable percentiles:

An error table providing a summary of all errors and their proportion in the total requests

A Top 5 Errors by Sampler table providing for every Sampler (excluding Transaction Controller by default) the top 5 Errors:

You can see that there are a lot of other types of reports too. You should explore these reports.

Create a Test Plan in JMeter

Sample Request

{
    "name": "Test",
    "job": "JMeter"
}

Sample Response

{
  "name":"Test",
  "job":"JMeter",
  "id":"955",
  "createdAt":"2023-07-03T15:46:18.038Z"
}


Step 1 –  Add Thread Group

  • Select Test Plan on the tree
  • Add Thread Group                                                                                                                               To add Thread Group: Right-click on the “Test Plan” and add a new thread group: Add -> Threads (Users) -> Thread Group

In the Thread Group control panel, enter Thread Properties as follows: We will take an example of row no 5

Number of Threads: 5 – Number of users connects to the target website
Loop Count: Infinite  – Number of times to execute testing
Ramp-Up Period: 5 – It tells JMeter how long to delay before starting the next user. For example, if we have 5 users and a 5 -second Ramp-Up period, then the delay between starting users would be 1 second (5 seconds /5 users).

Duration – 2 sec

Step 2 –  Adding JMeter elements  

The JMeter element used here is HTTP Request Sampler. In HTTP Request Control Panel, the Path field indicates which URL request you want to send


2.1 Add HTTP Request Sampler
To add: Right-click on Thread Group and select: Add -> Sampler -> HTTP Request

The below-mentioned are the values used in HTTP Request to perform the test

  • Name – HTTP POST Request Demo
  • Server Name or IP – reqres.in
  • Port – Blank
  • Method – POST
  • Path – /api/users

2.2 Add HTTP Head Manager

The Header Manager lets you add or override HTTP request headers like can add Accept-Encoding, Accept, Cache-Control

To add: Right-click on Thread Group and select: Add -> Config Element -> HTTP Read Manager

The below-mentioned are the values used in Http Request to perform the test
Content-type = application/json

Step 3 – Adding Listeners to Test Plan

Listeners – They show the results of the test execution. They can show results in a different format such as a tree, table, graph, or log file
We are adding the View Result Tree listener

View Result Tree – View Result Tree shows the results of the user request in basic HTML format
To add: Right-click on Test Plan, Add -> Listener -> View Result Tree

Aggregate Report

It is almost the same as Summary Report except Aggregate Report gives a few more parameters like, “Median”, “90% Line”, “95% Line” and “99% Line”.

 To add: Right Click on Thread Group > Add > Listener > Aggregate Report

Step 4 – Save the Test Plan

To Save: Click File Select -> Save Test Plan as ->Give the name of the Test Plan (POST_LoadDemo.jmx). It will be saved in .jmx format.

We are done! Congratulations on making it through this tutorial and hope you found it useful! Happy Learning!!

vibssingh

How to run SpringBoot project in GitLab CI/CD

Last Modified Date

HOME

This tutorial explains the process to run the SpringBoot project 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. Manually run the tests in the GitLab pipeline
    7. Check the status of the pipeline
    8. Download the report
      1. Example of SureFire-Report.html
      2. Example of Project Summary Report

Prerequisite:

  1. SpringBoot Starter Parent – 3.1.0
  2. Rest Assured – 5.3.0
  3. Java 17
  4. Maven – 3.8.6
  5. GitLab Account

Please refer to this tutorial to get the structure and code of the SpringBoot project – Testing of SpringBoot Application with JUnit5

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:

By default, GitLab will have CI/CD pipelines and Auto DevOps enabled for all projects. What this means is that, when you push code to the repository, GitLab will automatically trigger the pipeline.

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. I have already created .gitlab-ci.yml in the project, which can be seen in the 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 SpringBoot project (Maven) in the GitLab pipeline.

image: maven:3.8.5-openjdk-17
 
stages:
  - test
 
variables:
  MAVEN_OPTS: "-Dmaven.repo.local=.m2/repository"
 
test:
  stage: test
  allow_failure: true
 
# Run the tests
  script:
    - echo "Executing SpringBoot scenarios with maven"
    - mvn clean test site
 
# Store artifacts
  artifacts:
    when: always
    name: "SpringBoot Report"
    paths:
    - target/site/*
    expire_in: 24 h

Image – maven:3.8.5-openjdk-17 is used in this test. It is a docker image for Maven and have Java 17 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 – Manually run the tests in the GitLab pipeline

Whenever there is a new change committed, the pipeline runs automatically. Imagine the scenario when we need to run the pipeline without any new change. This can be done by clicking on the button “Run pipeline”.

Step 7 – 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 8 – Download the report

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

Example of SureFire-Report.html

Example of Project Summary Report

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

vibssingh

How to run SpringBoot tests with GitHub Actions

Last Modified Date

HOME

GitHub Actions is a powerful tool that can be used to automate your software development workflows. In this blog post, we will show you how to get started with GitHub Actions for Java Spring Boot.

Why GitHub?

The flexible aspects of GitHub Actions enable users to create powerful, fast, and efficient automated testing workflows in CI/CD environments.

CI/CD pipelines have contributed to the success of the DevOps cycle in all software development projects. This is a holistic process that bridges development and operations. Continuous integration helps development teams deploy code efficiently, and continuous delivery automates code deployment.

Implementation Steps

Step 1 – Create GitHub Actions and Workflows

I have a repository available on GitHub – SpringBoot_Serenity_Cucumber_JUnit4_Demo as shown in the below image. Go to the “Actions” tab.  Click on the “Actions” tab.

Step 2 – Select the type of Actions

You will see that GitHub recommends Actions depending on the project. In our case, it is recommending actions suitable for a Java project. I have selected the “Java with Maven” option as my project is built in Maven.

Step 3 – Generation of Sample pipeline

If you choose an existing option, it will automatically generate a .yaml for the project as shown below.

We will replace the current workflow with the following yml file as shown below:

name: Build and Test Java Spring Boot Application 

on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

jobs:
  build:

    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v3
    - name: Set up JDK 17
      uses: actions/setup-java@v3
      with:
        java-version: '17'
        distribution: 'temurin'
        cache: maven
   
    - name: Build with Maven
      run: mvn clean verify

    - name: Test Report
      uses: actions/upload-artifact@v3
      if: success() || failure()
      with:
          name: SpringBoot Report               # Name of the folder
          path: target/site/serenity/           # Path to test results

Step 4 – Commit the changes

After the changes, hit the “Commit changes” button.

This will give the option to add a description for the commit. It will enable the user to commit either to the main branch. The user can also commit to any other branch that exists in the project. Click on the “Commit changes” button to set up the workflow file.

Below is the image of the newly created maven.yml file.

Step 5 – Verify that the workflow is running

Next, head over to the “Actions” tab, and you will see your YAML workflow file present under the tab. The yellow sign represents that the job is in the queue.

In Progress – When the job starts building and running, you will see the status change from “Queued” to “in progress”.

Passed – If the build is successful, you will see a green tick mark. 

Failed – In case the build has failed, then there will be a red cross mark.

Click on the workflow and the below screen is displayed. It shows the status of the run of the workflow. It also shows the total time taken to run the workflow and the name of the .yml file.

Below shows all the steps of the workflow.

Step 6 – Published artifacts on GitHub

Once the pipeline run, a SpringBoot Report folder will be generated as shown in the below image:

When we click on the folder SpringBoot Report, a zipped file will be downloaded. We can extract it to see all the files contained within it.

The image of the report is shown below:

The complete code can be found here on GitHub – SpringBoot_Serenity_Cucumber_JUnit4_Demo.

Congratulations! We just created our CI workflow for running our SpringBoot test cases.

vibssingh

How to integrate Robot Framework with Jenkins

Last Updated On

HOME

In the previous tutorial, we have seen the Integration of Allure Report with Jenkins. In this tutorial, we show you how to integrate Robot Framework with Jenkins. 

Table Of Contents

  1. Prerequisite
  2. Implementation Steps
    1. Create a new FreeStyle project
    2. Select a custom workspace
    3. Build Management
    4. Select “Publish HTML reports” from “Post Build Actions”
    5. Execute the tests
    6. View the HTML Report

Prerequisite:

Jenkin’s installed and started on the computer. The current Jenkins version is – 2.361.2

Implementation Steps

To generate HTML Report in Jenkins, we need to download HTML Publisher Plugin. Please refer to this tutorial to install the plugin – How to install Plugins in Jenkins.

Step 1: Create a new FreeStyle project

  1. Give the Name of the project – RobotFramework_Demo
  2. Click on the Maven project. 
  3. Click on the OK button.

In the General section, enter the project description in the Description box.

Step 2: Select a custom workspace

Mention the full path of the project in the Use custom workspace.

Select Source Code Management as None if the project is locally present on the machine.

Step 3: Build Management

The source code used for this tutorial can be seen here – Page Object Model in Robot Framework with Selenium and Python.

Go to the Build section of the new job. Select “Execute Windows batch command”.

Mention the command needed to execute the tests. In this case, I have to execute all the tests, so used the below command:

Click on the Advanced button.

Step 4: Select “Publish HTML reports” from “Post Build Actions”

Scroll down to “Post Build Actions” and click on the “Add Post Build Actions” drop-down list. Select “Publish HTML reports“. 

If you want to see where the report is saved in Jenkins, go to the Dashboard -> RobotFramework_Demo -> Workspace -> report.html.

Enter the HTML directory to archive – Empty, Index page[s] – report.html, and Report title – HTML Report.

Click on the Apply and Save buttons.

We have created a new Maven project “RobotFramework_Demo” with the configuration to run the tests in the RobotFramework.

Step 5: Execute the tests

Let’s execute it now by clicking on the “Build Now” button. 

Right-click on Build Number (here in my case it is #3).

Click on Console Output to see the result.

Step 6: View the HTML Report

Once the execution is completed, click on go “Back to Project“, and we could see a link to view the “HTML Report“.

We can see here that the HTML Report link is displayed in the Console.

Below is the HTML Report generated in Jenkins.

There are chances that the report won’t look very pretty. The reason is that CSS is stripped out because of the Content Security Policy in Jenkins.

The default rule set in Jenkins is:

sandbox; default-src 'none'; img-src 'self'; style-src 'self';

To know more about this, please refer to this tutorial – https://www.jenkins.io/doc/book/security/configuring-content-security-policy/.

We can customize Content Security Policy in Jenkins. But keep in mind that it should be done after checking with the Security team in your organization. This is a workaround solution. I can’t emphasize enough that this is not a standard practice.

Go to Manage Jenkins -> Manage Nodes and Clouds.

Click on the Script Console option.

Type in the following command and Press Run. If you see the output as ‘Result:’ then the protection is disabled. Re-Run your build and you can see that the new HTML files archived will have the CSS enabled.

System.setProperty("hudson.model.DirectoryBrowserSupport.CSP","")

Re-run the HTMLReport_Demo project. Now you can see a properly rendered HTML Report.

Congratulations on making it through this tutorial and hope you found it useful! Happy Learning!! Cheers!!

Additional Tutorials

How to Install Python on Windows 11
How to install and setup Robot Framework for Python
How to rerun failed tests in Robot Framework
How to implement tagging in Robot Framework
 How to set variable values from Runtime command in Robot Framework
How to load data from CSV files in the Robot Framework?
vibssingh

How to run Selenium tests with GitHub Actions

Last Updated On

HOME

This tutorial explains the steps to create a GitHub Action for the Selenium tests and execute the tests in that workflow.

Table of Contents

  1. Why GitHub?
  2. Important points
  3. Implementation Steps
    1. Create GitHub Actions and Workflows
    2. Select the type of Actions
    3. Generation of Sample pipeline
    4. Commit the changes
    5. Verify that the workflow is running

Why GitHub?

The flexible aspects of Selenium WebDrivers and GitHub Actions enable users to create powerful, fast, and efficient automated testing workflows in CI/CD environments.

CI/CD pipelines have contributed to the success of the DevOps cycle in all software development projects. This is a holistic process that bridges development and operations. Continuous integration helps development teams deploy code efficiently, and continuous delivery automates code deployment.

Important points

1. We don’t need to think about the Chromedriver.exe we are using WebDriver Manager to handle that instead of adding it to our project like the example:

 WebDriverManager.chromedriver().setup();

From Selenium 4.6.0 onwards, we don’t need to add WebDriverManager dependency explicitly to the project, because Selenium has added an inbuilt tool to handle the drivers. 

2. The Selenium tests need to run in the headless mode. As we are using Chrome browser, use the below code:

          ChromeOptions options = new ChromeOptions();
          options.addArguments("--no-sandbox");
          options.addArguments("--disable-dev-shm-usage");
          options.addArguments("--headless");
	      driver = new ChromeDriver(options);

3. Install Chrome browser in ubuntu. Use the below code:

    - uses: browser-actions/setup-chrome@latest
    - run: chrome --version

Implementation Steps

Step 1 – Create GitHub Actions and Workflows

I have a repository available in GitHub – Selenium-TestNG as shown in the below image. Go to the “Actions” tab.  Click on the “Actions” tab.

Step 2 – Select the type of Actions

You will see that GitHub recommends Actions depending on the project. In our case, it is recommending actions suitable for a Java project. I have selected the “Java with Maven” option as my project is built in Maven.

Step 3 – Generation of Sample pipeline

If you choose an existing option, it will automatically generate a .yaml for the project as shown below.

We will replace the current workflow with the next yml file as shown below:

name: Selenium with TestNG - CI

on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

jobs:
  build:

    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v3
    - name: Set up JDK 17
      uses: actions/setup-java@v3
      with:
        java-version: '17'
        distribution: 'temurin'
        cache: maven
    
    - uses: browser-actions/setup-chrome@latest
    - run: chrome --version
    
    - name: Build with Maven
      run: mvn -B clean test

The workflow file usually consists of the below attributes:

name: Java CI with Maven Name of workflow: This is an optional attribute.The name of the workflow is denoted by the keyword “name”. If you wish to include multiple CI jobs in your project, it is recommended to name each one appropriately.
on: [push] :
On attribute – This attribute is mandatory and specifies the trigger for this workflow. There are several actions you can include such as push, pull request, release, etc. for more information on the events, check the official guide here.
jobs: Under the jobs attribute, groups together all the jobs that run in the workflow.
runs-on: ubuntu-latest Configures the job to run on the latest version of an Ubuntu Linux runner. This means that the job will execute on a fresh virtual machine hosted by GitHub
steps: Under this option, the actions used by the particular workflow, and the multiple jobs that would run under the workflow are mentioned. These jobs run in parallel. If you want to run the jobs in the order in the CI pipelines, you must add the “needs” attribute. It is crucial to ensure that every workflow has at least one job. In our sample workflow, we only have one job as shown in image above.
uses: actions/checkout@v3
The uses keyword specifies that this step will run v3 of the actions/checkout action. This is an action that checks out your repository onto the runner, allowing you to run scripts or other actions against your code (such as build and test tools). You should use the checkout action any time your workflow will run against the repository’s code.
uses: actions/setup-java@v3
with:
java-version: ’17’ 		This step uses the actions/setup-java@v3 action to install the specified version of the Java (this example uses v17).

Step 4 – Commit the changes

After the changes, hit the “Start Commit” button.

This will give the choice to add a description for the commit. It will also allow the user to commit either to the main branch or commit to any other branch that exists in the project. Click on the “Commit new file” button to set up the workflow file.

Step 5 – Verify that the workflow is running

Next, head over to the “Actions” tab, and you will see your YAML workflow file available under the tab. The yellow sign represents that the job is in the queue.

In Progress – When the job starts building and running, you will see the status change from “Queued” to “in progress”.

Passed – If the build is successful, you will see a green tick mark. 

Click on the workflow and the below screen is displayed. It shows the status of the run of the workflow, the total time taken to run the workflow, and the name of the .yml file.

Below are all the steps of the workflow.

Failed – In case the build has failed, then there will be a red cross mark.

To learn more about Chrome installation, please refer to this tutorial – browser-actions/setup-chrome.

The complete code can be found here on GitHub – vibssingh/Selenium-TestNG.

Congratulations! We just created our CI workflow for running our Selenium test cases.

vibssingh

GitHub Tutorials

Last Updated On

HOME

GitHub is a web-based version control system and collaboration platform for developers. It is the centre around which all things involving git revolve. GitHub allows software developers and engineers to create remote, public-facing repositories on the cloud for free. Once you’ve set up a repository on GitHub, you can copy it to your device, add and modify files locally, and then “push” your changes back to the repository where your changes are displayed for the public.

Chapter 1 How to create a new repository on GitHub
Chapter 2 How to delete a repository on GitHub
Chapter 3 How to Fork a GitHub repository
Chapter 4 How to clone a project from GitHub using Eclipse
Chapter 5 How to copy code from another version control to GitHub – GitHub Importer
Chapter 6 What is pull request in GitHub?
Chapter 7 How to run Selenium tests with GitHub Actions
Chapter 8 How to upload Artifacts in GitHub
Chapter 9 How to run Gradle tests with GitHub Actions
Chapter 10 How to run SpringBoot tests with GitHub Actions
Chapter 11 How to run Serenity tests with GitHub Actions
Chapter 12 How to run Rest API tests with GitHub Actions
Chapter 13 How to host Extent Report on GitHub Pages with Github Actions
Chapter 14 How to run Robot Framework in GitHub Actions
Chapter 15 How to run PyTest Framework in GitHub Actions – NEW
vibssingh

Integrate Gradle project with Jenkins

Last Updated On

HOME

In the previous tutorial, we have seen the Integration Of Jenkins With Selenium WebDriver. In this tutorial, we show you how to integrate the Gradle project with Jenkins. 

Table Of Contents

  1. Prerequisite
  2. Setup GRADLE_HOME in Jenkins
    1. Start the Jenkins server
    2. Log in to Jenkins UI
    3. Select Manage Jenkins
    4. Select the Global Tool Configuration option
    5. Setup JDK Path
    6. Setup Gradle Path
  3. Integrate Gradle Project with Jenkins
    1. Create a new project using the FreeStyle project plugin
    2. Enter the project description in the Description box
    3. Build Management
    4. Select “Publish TestNG Results” from “Post Build Actions”
    5. Execute the tests

Prerequisite

  1. Jenkins installed and started on the computer
  2. Gradle is installed on the machine

Setup GRADLE_HOME in Jenkins

Step 1: Start the Jenkins server

Open the browser and navigate to the localhost and the port in which Jenkins is running.

http://localhost:8080/

Step 2: Log in to Jenkins UI

You need to provide a username and password and click on Sign in button.

Step 3: Select Manage Jenkins

Go to Jenkins Dashboard. After that, click on the Manage Jenkins link as shown below:

Step 4: Select the Global Tool Configuration option

When we click on the “Manage Jenkins” link, we are redirected to the Manage Jenkins page, where we can see various types of options, including the “Global Tool Configuration” option.

Step 5: Setup JDK Path

We need to set the JDK path in Jenkins as shown below. To know more about setting up Java in Jenkins, please refer to this tutorial – How to configure Java and Maven in Jenkins.

Step 6: Setup Gradle Path

We need to set the Gradle path in Jenkins as shown below.

Click on the Add Gradle Installations button. Kindly note that by default, “Install Automatically” will be checked, so since we are going to use the Gradle installed on our local machine, “Install automatically” will install the latest version of Gradle, and you will also need to provide credentials to download the relevant Maven.

Provide the Gradle’s name as we gave as Gradle 7.3.3 because that is what is currently installed on my machine, and also provide the path of Gradle in the GRADLE_HOME textbox.

Click on the Apply and Save buttons.

Integrate Gradle Project with Jenkins

Step 1: Create a new project using the FreeStyle project plugin

  1. Give the Name of the project.
  2. Click on the Freestyle project. 
  3. Click on the OK button.

Step 2: Enter the project description in the Description box

In the general section, describe the project in the description section.

Click on the Advanced button. Mention the full path of the project.

Step 3: Build Management

Go to the Build section of the new job and select the option – “Invoke Gradle Script“.

Provide the below-mentioned information:

  1. In the Gradle version, enter – GRADLE_HOME.
  2. In the Tasks option section, enter “clean test”

Step 4: Select “Publish TestNG Results” from “Post Build Actions”

Scroll down to “Post Build Actions” and click on the “Add Post Build Actions” drop-down list.

Select “Publish TestNG Results“.

To know, how to install TestNG plugin, please refer to this tutorial – How to generate TestNG Report in Jenkins.

Enter TestNG XML Report Pattern as “**GradleReports/testng-results.xml” and click on the Save button

We have created a new project “Gradle_SeleniumTestNG_Demo” with the configuration to run TestNG Tests and also to generate TestNG Reports after execution using Jenkins.

Step 5: Execute the tests

Let’s execute it now by clicking on the “Build Now” button.


Right-click on Build Number (here in my case it is #2) and click on Console Output to see the result.

The below screen shows that the build failed because I failed one of the tests intentionally to show how the result looks with passed and failed tests.

Once the execution is completed, we could see a link to view ‘TestNG Results’.

Click on the TestNG Results. It displays the summary of the tests.

This way, we could integrate the Gradle project with Jenkins.

Congratulations on making it through this tutorial and hope you found it useful! Happy Learning!! Cheers!!

vibssingh

Run Selenium Tests in GitLab CI/CD

Last Updated on

HOME

This tutorial explains the process to run the Selenium Tests in the GitLab pipeline. This is a very important step towards achieving CI/CD. Ideally, the tests need to run after any change (minor/major) before merging the latest change to the master branch. Suppose there are 100 changes merged to the master branch in a day. It is expected to run the tests every time before deployment. In this case, any QA won’t want to start the tests manually 100 times in a day. Now, what should be done to overcome this problem. Now, adding tests to the GitLab pipeline comes into the picture. We can add a test stage to the pipeline and the tests will run automatically when the pipeline run.

Table of Contents

  1. Prerequisite
  2. What is GitLab CI/CD Workflow?
  3. What is a headless browser?
  4. Implementation Steps
    1. Create a new Maven Project
    2. Add the dependencies to the POM.xml
    3. Create the Test Code
    4. Create testng.xml to run the tests
    5. Run the tests through command line
  5. GitLab Section
    1. Create a blank project in GitLab
    2. Push the project from local repository to Gitlab Repository
    3. Create a .gitlab-ci.yml file in the project in GitLab
    4. Run the tests in the GitLab pipeline
    5. Check the status of the pipeline
    6. Download the report

Prerequisite

  1. Selenium
  2. TestNG/JUnit (for Assertions)
  3. Java 11
  4. Maven/ Gradle
  5. GitLab Account

What is GitLab CI/CD Workflow?

Build the proposed changes. Then, push the commits to a feature branch. This branch should be in a remote repository that’s hosted in GitLab. The push triggers the CI/CD pipeline for your project. Then, GitLab CI/CD runs automated scripts (sequentially or in parallel) to build as well as to test the application. After a successful run of the test scripts, GitLab CI/CD deploys your changes automatically to any environment (DEV/QA/UAT/PROD). But if the test stage is failed in the pipeline, then the deployment is stopped.

After the implementation works as expected:

  • Get the code reviewed and approved.
  • Merge the feature branch into the default branch.
    • GitLab CI/CD deploys your changes automatically to a production environment.

To use GitLab CI/CD, we need to keep 2 things in mind:

a) Make sure a runner is available in GitLab to run the jobs. If there is no runner, install GitLab Runner and register a runner for your instance, project, or group.

b) Create a .gitlab-ci.yml file at the root of the repository. This file is where CI/CD jobs are defined.

The Selenium tests run on a headless browser in the pipeline.

What is a headless browser?

A headless browser is like any other browser, but without a Head/GUI (Graphical User Interface).  A headless browser is used to automate the browser without launching the browser. While the tests are running, we cannot see the browser. However, we can see the test results coming on the console.

To explain, I have created 2 Selenium tests and used TestNG for asserting the tests. The tests will run on a headless Chrome browser. One more thing to keep in mind is that when tests run on a headless Chrome browser, the window screen won’t be full screen. So, the screen needs to be maximized explicitly otherwise some of the tests would fail.

Implementation Steps

Step 1 – Create a new Maven Project

Step 2- Add the dependencies to the POM.xml

Add the below-mentioned dependencies that need to add to the project to the pom.xml in Maven Project.

 <dependencies>

        <dependency>
            <groupId>io.github.bonigarcia</groupId>
            <artifactId>webdrivermanager</artifactId>
            <version>5.1.0</version>
        </dependency>

        <dependency>
            <groupId>org.seleniumhq.selenium</groupId>
            <artifactId>selenium-java</artifactId>
            <version>3.141.59</version>
        </dependency>

        <dependency>
            <groupId>org.testng</groupId>
            <artifactId>testng</artifactId>
            <version>7.5</version>
            <scope>test</scope>
        </dependency>
                   
    </dependencies>
    <build>
     <plugins>
     
     <!--  Compiler Plugin -->
    
    <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>3.8.1</version>
        <configuration>
           <source>11</source>
           <target>11</target>
        </configuration>
    </plugin>
     
      <!--  Plugin used to execute tests -->
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-surefire-plugin</artifactId>
        <version>3.0.0-M5</version>
        <configuration>
          <suiteXmlFiles>
            <suiteXmlFile>testng.xml</suiteXmlFile>
          </suiteXmlFiles>
        </configuration>
      </plugin>
     </plugins>
  </build>
</project>

As explained in one of the previous tutorial, it is needed to add the maven-surefire-plugin to run the TestNG tests through the command line.

Step 3 – Create the Test Code

This is the BaseTest Class. The WebDriver is initialized here. It operates in headless mode and full screen. At the end, the WebDriver is closed.

import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeDriver;
import org.openqa.selenium.chrome.ChromeOptions;
import org.testng.annotations.AfterMethod;
import org.testng.annotations.BeforeMethod;

import io.github.bonigarcia.wdm.WebDriverManager;

public class BaseTest {
	
	WebDriver driver;
	
	@BeforeMethod
	public void beforeTests() {
        WebDriverManager.chromedriver().setup();
        ChromeOptions options=new ChromeOptions();
        options.setHeadless(true);
        options.addArguments("window-size=1920,1200");
        driver=new ChromeDriver(options);
        driver.get("https://opensource-demo.orangehrmlive.com/");
    }

	@AfterMethod
    public void afterTests() {
        driver.quit();
    }

}

There are 2 different pages that need to be tested – LoginPage and ForgetPasswordPage

LoginPage contains the tests to log in to the application. After successful login, the application moves to the next webpage – HomePage. You can see that BaseTest class is extended in both the Test classes.

import org.openqa.selenium.By;
import org.testng.Assert;
import org.testng.annotations.Test;

@Test
public class LoginPage extends BaseTest{
	
	@Test
	public void validCredentials() throws InterruptedException {

	        driver.findElement(By.name("txtUsername")).sendKeys("Admin");	        
	        driver.findElement(By.name("txtPassword")).sendKeys("admin123");
	        driver.findElement(By.id("btnLogin")).click();
	         String newPageText = driver.findElement(By.xpath("//*[@id='content']/div/div[1]/h1")).getText();
	        System.out.println("newPageText :" + newPageText);
	        Assert.assertEquals(newPageText,"Dashboard");

	}

}

ForgetPasswordPage

import org.openqa.selenium.By;
import org.testng.Assert;
import org.testng.annotations.Test;

@Test
public class ForgetPasswordPage extends BaseTest{
	
	@Test
	public void getHeading() {
		
		Thread.sleep(1000);
		driver.findElement(By.xpath("//*[@id='forgotPasswordLink']/a")).click();
		String heading = driver.findElement(By.xpath("//*[@id='content']/div[1]/div[2]/h1")).getText();
		System.out.println("Title : "+ heading );
		Assert.assertEquals(heading, "Forgot Your Password?");
	}
	
}

Step 4 – Create testng.xml to run the tests

Now, let’s create a testng.xml to run the TestNG tests. If JUnit is used instead of TestNG, then this step is not needed.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE suite SYSTEM "https://testng.org/testng-1.0.dtd">
<suite name="Suite">
  <test name="Test">
    <classes>
      <class name="org.example.DockerDemo.LoginPage"/>
      <class name="org.example.DockerDemo.ForgetPasswordPage"/>
    </classes>
  </test> <!-- Test -->
</suite> <!-- Suite -->

Step 5 – Run the tests through command line

Now, let us execute the tests through the command line. Go to the place where the pom.xml of the project is placed and use the below command to run the tests. This step makes sure that all the tests are running as expected.

mvn compile test

GitLab Section

Step 6 – Create a blank project in GitLab

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

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

To know, how to push the changes in GitLab, please refer to this tutorial.

Step 8 – 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.
image: markhobson/maven-chrome

stages:
  - test

variables:
  MAVEN_OPTS: "-Dmaven.repo.local=.m2/repository"

test:
  stage: test
  allow_failure: true

# Run the tests  
  script:
    - mvn $MAVEN_OPTS clean package
    - mvn compile test

# Store artifacts
  artifacts:
    when: always
    name: "report"
    paths:
    - target/surefire-reports/*
    expire_in: 1 h

Image – markhobson/maven-chrome is used in this test. It is a docker image for Java automated UI tests.

This gitlab-ci.yml has only 1 stage. It is a test stage that contains the command to run the tests. It also creates an artifact that contains all the surefire reports. These reports can be saved as Test Evidence.

Step 9 – Run the tests in the GitLab pipeline

Now, when a new change is committed, a pipeline kicks off and it runs all the tests.

Step 10 – 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 failed here which means that the execution is completed. Let us see the logs of the execution it shows that out of 2 tests, 1 test passed and 1 test failed. This shows that tests are running successfully 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 “report” and the reports in this folder come from the path /target/surefire-reports. This artifact gives us the option to download the reports or browse the report. This report will be available for 1 hour only as mentioned in the gitlab-ci.yml.

Step 11 – Download the report

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

Example of Emailable-Report.html

Example of Index.html

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