Using Postman with Gitlab

Owned by Mike Deskis
Last updated: Nov 12, 2024 by Ioana Kocurova
5 min read

This article provides a step-by-step guide on how to use Postman with Gitlab for running tests. It explains the prerequisites, such as creating a new branch in Gitlab specifically for Postman tests, and then explains the three steps involved in the process. The steps include exporting the tests from Postman to your PC, uploading the exported file to the Gitlab branch, and editing the ".gitlab-ci.yml" file to include the necessary script for running the Postman tests. The article concludes by providing a link to an example of Postman tests running in the Gitlab pipeline.

Prerequisites

The prerequisites for using Postman with Gitlab involve two main steps. Firstly, you need to create a new branch in Gitlab that is dedicated specifically for Postman tests. This branch will be used to manage and store the Postman test files. Secondly, you need to export the tests from Postman in a specific format called "collection.json." This file contains all the information about the tests and is used to import the tests into Gitlab for integration with the pipeline.

In technical terms, a "branch" in Gitlab refers to a parallel version of the code within a repository, and creating a new branch allows you to work on new features or tests without affecting the main codebase. "Postman" is a popular API client that allows users to design, test, and document APIs, while "collection.json" is a file format used by Postman to store API requests and tests in a structured manner.

NOTE: Make sure to have new branch created in Gitlab, that will be used only for this Postman tests. Reason is that after we edit “.gitlab-ci.yml” file, we won’t be able to use this branch for Cypress tests.

Step 1: Export Tests

To export tests from Postman to your PC and save the package as "collection.json," follow these steps:

  • Right-click on your test folder, then select "export," and once again click on "export."

  • Finally, name the file "collection.json" and save it to your desired location on your PC.

NOTE: this shows user interface from Postman, it shows a request being constructed to a specific API endpoint.

Here is what this Postman panel is showing:

  • In the Body section of the request, we see a JSON payload that includes several key-value pairs. The keys are "apce," "CustomerId," "effectiveDate," and "products," with their respective values being "MMX," "0300961724," "2022-05-27," and an array of product IDs.

  • This JSON format is standard for sending data in a web API call, indicating that the user is attempting to send these details to the API endpoint defined in the request URL.

  • The JSON payload suggests that this API call is likely related to retrieving or manipulating data for a customer with the given ID, effective from the specified date, and involving the listed products.

  • The array under "products" contains one visible product ID "1000000013937," indicating that this part of the data specifies which products are relevant for this API call.

NOTE: The user interface also shows options for different types of request body formats such as form-data, x-www-form-urlencoded, raw, binary, and GraphQL, but JSON is selected, which is a common format for APIs due to its ease of use and readability.

  • The bottom right corner indicates that the user can click "Send" to execute the API call and receive a response, which would appear in the "Response" section below the request setup. The response would likely contain data or a confirmation relating to the operation performed by this API call.

Step 2: Upload

Upload the file named "collection.json" to your Gitlab branch, ensuring that you are working within the newly created branch.

NOTE: shows user interface of a version control platform, which appears to be GitLab, based on the layout and design. The interface is displaying a repository with various files and options. The focus is on a section where there are options to upload new files to the repository.

Here is what we see on this panel:

NOTE: This kind of interface is typically used by developers to manage and share their codebase, allowing for collaborative work on software projects, where they can track changes, revert to previous versions if necessary, and merge contributions from different team members.

Step 3: Edit .gitlab-ci.yml File

Edit the ".gitlab-ci.yml" file in your Gitlab repository. If the file doesn't exist in the repository, create a new one and name it ".gitlab-ci.yml." Replace the existing content in the file with the provided text shown below:

 

stages:     - test postman_tests:     stage: test     image:          name: postman/newman:alpine         entrypoint: [""]     script:         - newman --version         - newman run collection.json

b-ci.

CODE REVIEW: this is a snippet of a CI/CD (Continuous Integration/Continuous Deployment) pipeline configuration, specifically for running Postman tests using Newman in a Docker container.

Here's a breakdown of the YAML configuration:

  • The stages section defines a single stage named test.

  • The postman_tests section describes a job that is part of the test stage.

  • The image section specifies the Docker image to be used, which is postman/newman:alpine. This indicates that the job will run in a lightweight Alpine Linux container with Newman pre-installed.

  • The entrypoint is overridden with an empty array [""], which is a common practice when you want to customize the default command that the Docker container runs at startup.

  • The script section contains commands that will be executed in this job:

    • newman --version is likely used to print the Newman version for logging or debugging purposes.

    • newman run collection.json is the main command that executes the Postman collection tests using Newman.

NOTE: Newman is a command-line collection runner for Postman, which allows you to run and test a Postman collection directly from the command line. It's widely used for automating the testing of APIs and for integrating with CI/CD pipelines to ensure that any new changes do not break existing functionality.