GitLab is a web-based Git repository that provides free open and private repositories, issue-following capabilities, and wikis. It is a complete DevOps platform that enables professionals to perform all the tasks in a project—from project planning and source code management to monitoring and security.
In this tutorial, I will explain how we can clone a project from GitLab in Eclipse.
Implementation Steps
Step 1– Go to GitLab and select the project which you want to clone. Click on the blue color “Clone” button then copy the hyperlink as shown in the image. You can either Clone with SSH or Clone with HTTPS.
Step 2 – Open Eclipse and go to “File > Import” in eclipse as shown in the image.
Step 3– A window will pop up in which select Git Folder. Under the Git folder, select the option – “Projects from Git(with smart import)”as shown in the image.
Click on the “NEXT” button.
Step 4 – A new window will pop up in which select the option – “Clone URI” as shown in the image.
Click on the “NEXT” button.
Step 5 – Another window will pop up in which you have to paste the“GitLab Repository URL” and also“GitLab UserID and Password” and click on the “Next” button.
URI – This is the URL that we have cloned from GitLab in Step 1. Host – gitlab.com Repository path – path of the project in GitLab (This is auto-populated after entering URI)
Authentication User – Username of GitLab Password – password of GitLab
Step 6 – Select master and select “When fetching a commit, also fetch its tags“.
Click on the “Next” button.
Step 7 – Select the “Folder directory” in which you want to import the repository.
Click on the “Finish” button.
Step 8 – We have successfully imported the GitLab Repository as shown in the below image.
Congratulations on making it through this tutorial and hope you found it useful! Happy Learning!! Cheers!!
GitLab is the open DevOps platform, delivered as a single application. This makes GitLab unique and creates a streamlined software workflow, unlocking your organization from the constraints of a pieced-together toolchain. Learn how GitLab offers unmatched visibility and higher levels of efficiency in a single application across the DevOps lifecycle.
GitLab is a web-based Git repository that provides free open and private repositories, issue-following capabilities, and wikis. It is a complete DevOps platform that enables professionals to perform all the tasks in a project from project planning and source code management to monitoring and security.
Why Use GitLab?
The primary advantage of using GitLab is that it allows all team members to collaborate at all stages of the project. GitLab provides tracking from planning to creation to assist developers in automating the entire DevOps lifecycle and achieving the best results possible. GitLab is becoming increasingly popular among developers due to its extensive set of features and code building blocks.
In this tutorial, I will explain how we can clone a project from GitLab in IntelliJ.
Implementation Steps
Clone the project from GitLab
Step 1 – Go to GitLab and select the project that you want to clone. Click on the blue colour “Clone” button, then copy the hyperlink as shown in the image. You can either Clone with SSH or Clone with HTTPS.
Import the cloned project in IntelliJ
Step 2– From the main menu, select Git -> Clone
Another way is File ->New -> Project from Version Control
Step 3 – In the Get from Version Controldialog, specify the URL of the remote repository you want to clone. This is retrieved from Step 1. Click the Clone button.
Step 4– A dialog box will appear to log in to GitLab. Provide the username and password of GitLab. Select the “Log In” button.
Step 5– When you import or clone a project for the first time, IntelliJ IDEA analyses it. If the IDE detects more than one configuration (for example, Eclipse and Gradle), it prompts you to select which configuration you want to use. Select the necessary configuration and click the OK button. I have selected the Maven project.
Step 6– Once I have selected the Maven project, a new dialog box will appear. IntelliJ asks you to either Trust the Project or Preview it in Safe Mode. I trust the project, so I have selected the Trust Project button.
Step 7– IntelliJ will ask if you want to open the project in the current window or New Window. It is always a good practice to open the project in a New Window.
Step 8– We have successfully imported the GitLab Repository as shown in the below image.
Congratulations on making it through this tutorial and hope you found it useful! Happy Learning!! Cheers!!
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.
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.
Description – Provide the description of the project
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.
Cron TimeZone – Mention the timezone in which the job should run. Here, I have used [UTC+1]Dublin timezone.
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.
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.
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.
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 :
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
Congratulations. This tutorial has explained the steps to schedule the pipeline in GitLab CI/CD. Happy Learning!!
This tutorial explains the process to run the Selenium Tests on multiple browsers 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. This makes life of a QA very easy.
Once the proposed changes are built, then push the commits to a feature branch 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.
How to check if GitLab Runner is configured?
Go to the project created in the GitLab. Go to the left side and click on Settings. Go to CI/CD option and a CI/CD Settings page open. Scroll down and see the Runners. By default, Shared runner will be selected for any new project.
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 could not see the browser, but we can see the test results coming on the console.
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 where the WebDriver is initialized, headless mode, full screen, and at the end close the WebDriver.
package com.example.tests;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.chrome.ChromeOptions;
import org.openqa.selenium.edge.EdgeOptions;
import org.openqa.selenium.firefox.FirefoxOptions;
import org.openqa.selenium.remote.RemoteWebDriver;
import org.testng.annotations.AfterMethod;
import org.testng.annotations.BeforeMethod;
import org.testng.annotations.Parameters;
import java.net.URL;
import java.time.Duration;
public class BaseTests {
protected static ThreadLocal<RemoteWebDriver> driver = new ThreadLocal<RemoteWebDriver>();
public static String remote_url = "http://selenium-hub:4444";
public final static int TIMEOUT = 5;
@BeforeMethod
@Parameters("browser")
public void setUp(String browser) throws Exception {
if(browser.equalsIgnoreCase("chrome")) {
ChromeOptions options = new ChromeOptions();
options.addArguments("--start-maximized");
options.addArguments("--headless=new");
options.addArguments("--remote-allow-origins=*");
driver.set(new RemoteWebDriver(new URL(remote_url), options));
System.out.println("Browser Started :"+ browser);
} else if (browser.equalsIgnoreCase("firefox")) {
FirefoxOptions options = new FirefoxOptions();
options.addArguments("--start-maximized");
options.addArguments("-headless");
driver.set(new RemoteWebDriver(new URL(remote_url), options));
System.out.println("Browser Started :"+ browser);
} else if (browser.equalsIgnoreCase("edge")) {
EdgeOptions options = new EdgeOptions();
options.addArguments("--start-maximized");
options.addArguments("--headless=new");
driver.set(new RemoteWebDriver(new URL(remote_url), options));
System.out.println("Browser Started :"+ browser);
} else {
throw new Exception ("Browser is not correct");
}
driver.get().get("https://opensource-demo.orangehrmlive.com/");
driver.get().manage().timeouts().implicitlyWait(Duration.ofSeconds(TIMEOUT));
}
public WebDriver getDriver() {
return driver.get();
}
@AfterMethod
public void closeBrowser() {
driver.get().quit();
driver.remove();
}
}
There is a Login pages that need to be tested.
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 here.
package com.example.tests;
import org.openqa.selenium.By;
import org.testng.annotations.Test;
import static org.testng.Assert.assertEquals;
public class LoginPageTests extends BaseTests {
By userName = By.name("username");
By passWord = By.name("password");
By loginBtn = By.xpath("//*[@id='app']/div[1]/div/div[1]/div/div[2]/div[2]/form/div[3]/button");
By errorMessage = By.xpath("//*[@id='app']/div[1]/div/div[1]/div/div[2]/div[2]/div/div[1]/div[1]/p");
By blankUsername = By.xpath("//*[@id='app']/div[1]/div/div[1]/div/div[2]/div[2]/form/div[1]/div/span");
By dashboardPage = By.xpath("//*[@id='app']/div[1]/div[1]/header/div[1]/div[1]/span/h6");
@Test
public void invalidCredentials() {
getDriver().findElement(userName).sendKeys("1234");
getDriver().findElement(passWord).sendKeys("12342");
getDriver().findElement(loginBtn).click();
String actualErrorMessage = getDriver().findElement(errorMessage).getText();
System.out.println("Actual ErrorMessage :" + actualErrorMessage);
assertEquals(actualErrorMessage,"Invalid credentials");
}
@Test
public void blankUsername() {
getDriver().findElement(userName).sendKeys("");
getDriver().findElement(passWord).sendKeys("12342");
getDriver().findElement(loginBtn).click();
String actualErrorMessage = getDriver().findElement(blankUsername).getText();
System.out.println("Actual ErrorMessage :" + actualErrorMessage);
assertEquals(actualErrorMessage,"Required");
}
@Test
public void successfulLogin() {
getDriver().findElement(userName).sendKeys("Admin");
getDriver().findElement(passWord).sendKeys("admin123");
getDriver().findElement(loginBtn).click();
String actualMessage = getDriver().findElement(dashboardPage).getText();
System.out.println("Message :" + actualMessage);
assertEquals(actualMessage,"Dashboard");
}
}
Step 4 – Create testng.xml to run the tests
Now, let’s create a testng.xml to run the TestNG tests. It is very easy to create testng.xml in the case of Eclipse. Right-click on the project, and select TestNG -> Convert to TestNG. It will create a basic testng.xml structure. In case of IntelliJ, create a new file with the name of testng.xml and copy the code from here.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE suite SYSTEM "https://testng.org/testng-1.0.dtd">
<suite name="Suite" parallel="tests" thread-count="3">
<test name="Chrome Test">
<parameter name="browser" value="chrome"></parameter>
<classes>
<class name="com.example.tests.LoginPageTests"/>
</classes>
</test> <!-- Test -->
<test name="Firefox Test">
<parameter name="browser" value="firefox"></parameter>
<classes>
<class name="com.example.tests.LoginPageTests"/>
</classes>
</test> <!-- Test -->
<test name="Edge Test">
<parameter name="browser" value="edge"></parameter>
<classes>
<class name="com.example.tests.LoginPageTests"/>
</classes>
</test> <!-- Test -->
</suite> <!-- Suite -->
version: 3. It is the latest version of the docker-compose files.
services(containers): This contains the list of the images and their configurations.
image: It defines which image will be used to spin up container.
ports: Published ports with host:container format.
container_name: You can give name to your containers.
depends_on: This defines the required dependency before spinning up the container. In our docker-compose.yml file, containers Chrome and Firefox are dependent upon container hub to spin up.
SE_NODE_MAX_INSTANCES: This defines how many instances of same version of browser can run over the Remote System.
SE_NODE_MAX_SESSIONS: This defines maximum number of concurrent sessions that will be allowed.
Step 6 – Create a .gitlab-ci.yml
stages:
- test
variables:
SELENIUM_SERVER_NAME: selenium-hub
SELENIUM_SERVER_URL: http://${SELENIUM_SERVER_NAME}:4444
DOCKER_HOST: tcp://docker:2375
services:
- docker:20.10.16-dind
test:
stage: test
image: docker/compose
before_script:
- docker-compose up -d selenium-hub chrome edge firefox
- sleep 10
- docker-compose run ping curl ${SELENIUM_SERVER_URL}/status
script:
- docker-compose run tests mvn clean test
artifacts:
when: always
name: "report"
paths:
- target/surefire-reports/**
expire_in: 7 days
GitLab Section
Step 7 – Create a blank project in GitLab
To know, how to create a blank new project in GitLab, please refer tothis tutorial.
Step 8 – Push the project from local repository to Gitlab Repository
To know, how to push the changes in GitLab, please refer to this tutorial.
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 9 tests, all 9 are passed. This shows that tests ran 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 7 days 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!!
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:
The Serenity tests run on a headless browser in the pipeline.
What is a headless browser?
A headless browser is a web browser that operates without a graphical user interface (GUI). It is typically used for automated testing, web scraping, and server-side rendering of web pages. While traditional web browsers like Chrome, Firefox, or Safari have a visible interface for users to interact with, headless browsers work in the background and don’t display the web content visually.
Why do we use Headless browser for executing tests in CI/CD pipeline?
Headless browsers provide a consistent and controlled environment for running tests. They eliminate the variability introduced by different operating systems, browser versions, or screen resolutions, ensuring that tests produce consistent and reliable results across different environments.
Headless browsers can often execute tasks faster than their graphical counterparts. They don’t need to render and display web content, which can significantly reduce the execution time for automated tests or other web-related tasks, contributing to faster feedback in the CI/CD pipeline.
In the below example, our tests are in headless mode.
WebDriverManager.chromedriver().setup();
ChromeOptions ops = new ChromeOptions().setHeadless(true);
ops.addArguments("--remote-allow-origins=*");
driver = new ChromeDriver(ops);
To know, how to create a blank new project in GitLab, please refer tothis tutorial.
Step 2 – Push the project from local repository to Gitlab Repository
To know, how to push the changes in GitLab, please refer to this tutorial.
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 Cucumber tests in the GitLab pipeline.
image: markhobson/maven-chrome
stages:
- test
variables:
MAVEN_OPTS: "-Dmaven.repo.local=.m2/repository"
test:
stage: test
allow_failure: true
# Run the tests
script:
- echo "Executing BDD scenarios with maven"
- mvn clean test
# Store artifacts
artifacts:
when: always
name: "Cucumber Report"
paths:
- target/*
expire_in: 24 h
Image – markhobson/maven-chrome is used in this test. It is a docker image for Java automated UI tests.
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 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 – 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 5 – 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, it’s 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 “Cucumber_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 5 – Download the report
Once, will click on the download button, it will download “Cucumber_Report.zip”. Unzip the folder and it looks like something as shown below:
Example of Overview Features
Example of Overview Tags
Example of Overview Steps
Congratulations. This tutorial has explained the steps to run Cucumber tests in GitLab CI/CD. Happy Learning!!
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.
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!!
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.
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!!
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:
The Serenity 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 could not see the browser, but we can see the test results coming on the console. The tests can run in the GitLab pipeline if the tests run in the headless mode.
To know, how to create a blank new project in GitLab, please refer tothis tutorial.
Step 2 – Push the project from the local repository to GitLab Repository
To know, how to push the changes in GitLab, please refer to this tutorial.
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 Serenity tests in the GitLab pipeline.
image: markhobson/maven-chrome
stages:
- test
variables:
MAVEN_OPTS: "-Dmaven.repo.local=.m2/repository"
test:
stage: test
allow_failure: true
# Run the tests
script:
- echo "Executing BDD scenarios with maven"
- mvn clean verify
# Store artifacts
artifacts:
when: always
name: "Serenity Report"
paths:
- target/site/*
expire_in: 24 h
Image – markhobson/maven-chrome is used in this test. It is a docker image for Java automated UI tests.
This command lets the pipeline continue running subsequent jobs, even if the previous job is failed.
allow_failure: true
The below command is used to execute the tests from Maven in the docker image.
mvn clean verify
The below command means that the artifact should be generated every time the pipeline is run, irrespective of the fact if the job is successful or failed.
artifacts:
when: always
The below command provides the name of the artifact. If this is not used, then the artifacts file is named artifacts, which becomes artifacts.zip when downloaded.
artifacts:
name: "Serenity Report"
The below command provides the path of the files that should be present in the artifact.
artifacts:
paths:
- target/site/*
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 – 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 5 – 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.
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 6 – Download the report
Once, will click on the download button, it will download “Serenity_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!!
This tutorial explains the process to run the Rest API Tests in the GitLab pipeline. This is a significant step towards achieving CI/CD. Ideally, the tests need to run after any change (minor/major) before merging the change to the master branch. Suppose there are 100 changes in a day, and any QA won’t want to start the tests manually 100 times in a day. So, 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, or we can schedule the tests to run automatically every hour or day using GitLab pipeline.
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 you define your CI/CD jobs.
Create a Rest API Project
Step 1 – Create a new Maven Project
Step 2 – Add dependencies to the project
Add the below-mentioned pom.xml which shows all the dependencies that need to add to the project.
It is needed to add maven-surefire plugin to run the TestNG tests through command line. To know more about this, please refer to this tutorial.
Step 3 – Create the Test Code to test the Rest API
Here, 2 tests are created. One of the tests gets all the employee data (GET) whereas another test creates an employee (POST).
import static io.restassured.RestAssured.given;
import static org.hamcrest.Matchers.equalTo;
import org.json.JSONObject;
import org.testng.annotations.Test;
import io.restassured.http.ContentType;
public class RestAPIDemo {
@Test(description = "To get the details of employee with id 2", priority = 0)
public void verifyUser() {
// Given
given()
// When
.when().get("http://dummy.restapiexample.com/api/v1/employee/2")
// Then
.then().statusCode(200).statusLine("HTTP/1.1 200 OK")
// To verify booking id at index 2
.body("data.employee_name", equalTo("Garrett Winters"))
.body("message", equalTo("Successfully! Record has been fetched."));
}
@Test(description = "To create a new employee", priority = 1)
public void createUser() {
JSONObject data = new JSONObject();
// Map<String, String> map = new HashMap<String, String>();
data.put("employee_name", "APITest");
data.put("employee_salary", "99999");
data.put("employee_age", "30");
// GIVEN
given().baseUri("http://dummy.restapiexample.com/api").contentType(ContentType.JSON).body(data.toString())
// WHEN
.when().post("/v1/create")
// THEN
.then().statusCode(200).body("data.employee_name", equalTo("APITest"))
.body("message", equalTo("Successfully! Record has been added."));
}
}
Step 4 – Create testng.xml to run the tests through TestNG
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="com.example.RestAssured_TestNG_Demo.RestAPIDemo"/>
</classes>
</test> <!-- Test -->
</suite> <!-- Suite -->
Step 5 – Run the tests through the command line
Now, let us execute the tests through the command line. Go to the place where 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.
Step 8 – Create .gitlab-ci.yml file in the project in GitLab
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.
Whether you want to run the scripts automatically or trigger any of them manually.
image: adoptopenjdk/maven-openjdk11
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
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. Here, the pipeline is passed with brown colour means that the execution of the test is completed with some failures.
I have added an artifact in the gitalb-ci.yml with the name “report”. 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 an 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
Click on the Download button and the report zip file is downloaded. Unzip the folder, and it contains all different types of surefire-reports.
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!!
QA Automation Expert 