How to run PyTest Framework in GitHub Actions

Last Updated On

HOME

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

Table of Contents

Why GitHub?

GitHub serves as a collaborative platform that supports version control, code collaboration, automated testing, and issue tracking, all of which are crucial elements in the software testing process. It promotes transparency, collaboration, and efficiency in the development and testing workflows.

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 in GitHub – “PyTest_Framework” 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 “Python application” 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: PyTest Framework - Python
on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

permissions:
  contents: read

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4
      - name: Set up Python 3.12.1
        uses: actions/setup-python@v4
        with:
          python-version: 3.12.1

      - name: Install dependencies
        run: |
          python -m pip install --upgrade pip
          pip install pytest
          pip install pytest-selenium
   
      - name: Test with PyTest
        run: pytest --html=tests/Reports/Report.html  

      - name: Test Report Generation
        uses: actions/upload-artifact@v4
        if: success() || failure()
        with:
          name: Pytest Report           # Name of the folder
          path: tests/Reports           # Path to test results

python -m pip install --upgrade pip

pip install pytest
pip install pytest-selenium

  - name: Test with PyTest
    run: pytest --html=tests/Reports/Report.html  

Step 4 – Commit the changes

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

This will give the option to add a description for the commit. It will also enable the user to commit either to the main branch or commit to any other branch that exists in the project. My personal prefernece is to create a new branch like shown below and then commit the changes in that new branch.

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. 

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 shows all the steps of the workflow.

The complete code can be found here on GitHub – vibssingh/PyTest_Framework.

Congratulations! We just created our CI workflow for running our Python Robot Framework.

How to run Python Rest API tests with GitHub Actions

Last Updated On

HOME

This tutorial explains the steps to create a GitHub Action for the Rest API tests built in Python and execute the tests in that workflow.

Table of Contents

Why GitHub?

Implementation Steps

Step 1 – Create GitHub Actions and Workflows

I have a repository available in GitHub – RestAPITesting_Python 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 Python project. I have selected the “Python application” option.

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:

# This workflow will install Python dependencies, run tests and lint with a single version of Python
# For more information see: https://docs.github.com/en/actions/automating-builds-and-tests/building-and-testing-python

name: Python application

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

permissions:
  contents: read

jobs:
  build:

    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v3
    - name: Set up Python 3.12.1
      uses: actions/setup-python@v3
      with:
        python-version: "3.12.1"
   
    - name: Install dependencies
      run: |
        python -m pip install --upgrade pip
        pip install pytest
        pip install requests
       
    - name: Test with pytest
      run: |
        cd TestCases
        pytest  --verbose --capture=no

Step 4 – Commit the changes

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

This will give the option to add a description for the commit. It will also enable 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 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. 

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 shows all the steps of the workflow.

The complete code can be found here on GitHub – vibssingh/RestAPITesting_Python.

Congratulations! We just created our CI workflow for running our Rest API test cases for Python.

How to run Robot Framework in GitHub Actions

Last Updated On

HOME

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

Table of Contents

Why GitHub?

GitHub serves as a collaborative platform that supports version control, code collaboration, automated testing, and issue tracking, all of which are crucial elements in the software testing process. It promotes transparency, collaboration, and efficiency in the development and testing workflows.

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 in GitHub – RobotFramework_POM 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 “Python application” 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: Robot Framework - Python
on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

permissions:
  contents: read

jobs:
  test:
    runs-on: ubuntu-latest
    
    steps:
      - uses: actions/checkout@v3
      - name: Set up Python 3.12.1
        uses: actions/setup-python@v3
        with:
          python-version: 3.12.1
  
      - name: Install dependencies
        run: |
          python -m pip install --upgrade pip
          pip install robotframework
          pip install robotframework-seleniumlibrary
  
      - name: Test with RobotFramework
        run: robot .  
        
      - name: Test Report Generation
        uses: actions/upload-artifact@v4
        if: success() || failure()
        with:
          name: Report                # Name of the folder
          path: report.html           # Path to test results

python -m pip install --upgrade pip

pip install robotframework
pip install robotframework-seleniumlibrary

Step 4 – Commit the changes

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

This will give the option to add a description for the commit. It will also enable 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 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. 

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 shows all the steps of the workflow.

The complete code can be found here on GitHub – vibssingh/RobotFramework_POM.

Congratulations! We just created our CI workflow for running our Python Robot Framework.

GIT Tutorials

Last Updated On

HOME

Git is a Distributed Version Control System (VCS) which is originally developed in 2005 by Linus Torvalds (Creator of Linux) and is open source, i.e. freely available to use. It is the most popular and most used version control tool right now. A staggering number of software projects rely on Git for version control, including commercial projects as well as open source. 

Chapter 1 How to install Git on Windows 10
Chapter 2 How to create a new Git Repository – git init Command
Chapter 3 How to stage changes in Git – git add Command
Chapter 4 How to unstage the changes in Git – git rm command
Chapter 5 How to commit changes in GIT – git commit command
Chapter 6 How to track commits in Git – git log command
Chapter 7 How to commit an empty folder in GIT – gitkeep
Chapter 8 How to ignore files in GIT – gitignore
Chapter 9 How to create a branch in GIT
Chapter 10 How to stash changes in GIT – git stash command
Chapter 11 How to push new local GIT Repository to GitLab
Chapter 12 How to change a remote repository’s URL using git? – NEW

How to change a remote repository’s URL using git?

HOME

git remote -v

git remote set-url origin https://github.com/vibssingh/Serenity_Cucumber_JUnit5.git

How to run Rest API tests with GitHub Actions

Last Updated On

HOME

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

Table of Contents

Why GitHub?

GitHub serves as a collaborative platform that supports version control, code collaboration, automated testing, and issue tracking, all of which are crucial elements in the software testing process. It promotes transparency, collaboration, and efficiency in the development and testing workflows.

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 in GitHub – RestAssured_TestNG_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: Rest API Tests using Rest Assured with TestNG
 
on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]
 
jobs:
  build:
 
    runs-on: ubuntu-latest
 
    steps:
    - uses: actions/checkout@v4
    - name: Set up JDK 17
      uses: actions/setup-java@v4
      with:
        java-version: '17'
        distribution: 'temurin'
        cache: maven
     
    - name: Test Execution
      run: mvn clean test
       
    - name: Test Report Generation
      uses: actions/upload-artifact@v4
      if: success() || failure()
      with:
          name: TestNG Report                 # Name of the folder
          path: target/surefire-reports/      # Path to test results

Step 4 – Commit the changes

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

This will give the option to add a description for the commit. It will also enable 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 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. 

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 shows all the steps of the workflow.

The complete code can be found here on GitHub – vibssingh/RestAssured_TestNG_Demo.

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

How to run Serenity tests with GitHub Actions

Last Updated On

HOME

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

Table of Contents

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. The Serenity Web tests need to run in the headless mode. As we are using Chrome browser, use the below code in the serenity.config:

          headless.mode = true

2. 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 – Serenity_Cucumber-JUnit5 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: Serenity Tests in GitHub
 
on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]
 
jobs:
  build:
 
    runs-on: ubuntu-latest
 
    steps:
    - uses: actions/checkout@v4
    - name: Set up JDK 17
      uses: actions/setup-java@v4
      with:
        java-version: '17'
        distribution: 'temurin'
        cache: maven

    - uses: browser-actions/setup-chrome@latest
    - run: chrome --version
    
    - name: Build with Maven
      run: mvn clean verify
       
    - name: Test Report Generation
      uses: actions/upload-artifact@v4
      if: success() || failure()
      with:
          name: Serenity Report                 # Name of the folder
          path: target/site/serenity/           # Path to test results

Step 4 – Commit the changes

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

This will give the option to add a description for the commit. It will also enable 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 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. 

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 shows all the steps of the workflow.

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

The complete code can be found here on GitHub – vibssingh/Serenity_Cucumber_JUnit5.

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

How to stash changes in GIT – git stash command

HOME

The previous tutorial has explained about committing the changes in GIT. This tutorial explains about stashing the changes in GIT.

What is git stash?

git stash temporarily stashes or shelves the changes made in the working copy so that we can work on something else and later apply these changes.

Imagine a situation where you are working on updating a feature, but suddenly there is a production bug in the existing functionality of the feature that needs to be fixed immediately. So, we need to switch to a bug fix and leave working on the update work. As the update work is not completed, we can stash these changes and work on the bug fix. Later, we can re-apply our stashed changes back to the code.

The git stash command can stash the uncommitted changes (both staged and unstaged), save them away for later use, and then revert them from your working copy. 

How to reapply stashed changes?

To re-apply the stashed changes, use this command

git stash pop

This command removes the changes from your stash and reapplies them to your working copy.

Alternatively, you can reapply the changes to your working copy and keep them in your stash with : 

git stash apply

Stashing untracked or ignored files

If a new file is created and not staged, then git stash is not going to stash that file.

Adding the -u option (or –include-untracked) tells git stash to also stash your untracked files:

git stash -u

Congratulation!! We have learned about stash in GIT.

How to push new local GIT Repository to GitLab

HOME

This tutorial explains the steps that need to be followed to push a new local GIT Repository to GitLab.

What is GitLab?

GitLab is a single application that spans the entire software development lifecycle. GitLab is an open-source project maintained by GitLab Inc with over 3,000 contributors. We can install and self-manage the GitLab Community Edition which is fully open-source under an MIT license. GitLab also provides an Enterprise Edition that has additional features built upon the open-source edition. 

GitLab’s application offers functionality to collaboratively plan, build, secure, and deploy software as a complete DevOps Platform.

Create an empty repo in GitLab:

Step 1 – Login to GitLab using your username and password.

Step 2 – In the dashboard, click the blue New project button. This opens the New project page.

Step 3 – Select Create a blank project.

Step 4 – A new page will open. Provide the following information on that page:

1. Project Name – Mention the name of your project in the Project name field – GitTest.

2. Project slug – When a name is added, the Project slug auto-populates. This is the URL path for your project that the GitLab instance uses.

3. Project description (optional)  – This field enables you to enter a description for your project’s dashboard, which helps others understand what your project is about.

4. Visibility Level – Select the appropriate Visibility Level for your project. I have selected private option.

5. I’m not checking ReadMe option as I already have a ReadMe file in my project.

Select the Create Project button.

We can see that a new empty project is created in the GitLab as shown below.

Step 5 – For every remote repo, you will get a unique URL as highlighted below. This URL is used to push the local changes to this remote repo. Type the below command in GitBash:

git remote add origin https://gitlab.com/vibhasingh2004/gittest.git

To open GitBash, go to the location where the project is saved and Right Click and Select GitBash Here.

Add remote URL to local GIT Repository

git remote command provide the name to direct link to Repositories.

git remote command is used in conjunction with the git fetch, git push, and git pull commands.

git remote -v

This command list the remote connections we have to other repositories along with the URL of each connection.

Push the local changes to a remote repo

To push the changes from GIT Local Repository to GitLab in a particular branch of the remote repo, we need to use the below command:

git push <remote url or name> <branch name>

git push origin master

origin is the alias name of the full GIT Repository path (https://gitlab.com/vibhasingh2004/gittest.git)

Now run the Git push command as shown above. It will ask for your GitLab credentials in a new window as shown below. Please provide the username and password used to log in to GitLab.

Now we can see we have successfully pushed the local changes to the remote repository. Let’s go to GitLab and verify the latest changes. All the files from the local GIT Repository are moved to GitLab Remote Repository.

I hope this tutorial has helped you to set up a new project in GitLab and push the local changes to GIT Remote Repository.

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.

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!!