My experience using GitHub Actions to automate a Postman API Testing Project
My favorite part of working on any automation project is implementing CI/CD. So far, I’ve been using Jenkins as the CI/CD tool for most of my projects. However, I wanted to explore GitHub Actions for CI/CD as part of a recent API testing project.
The idea came up when one of my team members mentioned that she didn’t have Jenkins on her machine and wanted to see real-time CI/CD in action. We didn’t have a dedicated Jenkins server then—only local Jenkins instances installed on our local machines, where we manually triggered builds. Eventually, I figured out how to set up a Jenkins pipeline on my local machine and automatically trigger builds. More on that in this blog here.
This blog will explain how I set up GitHub Actions for our "API testing using Postman" project. I'll show how I automated the execution of Postman tests and generated a beautiful Newman HTML report—all without relying on Jenkins or any other external CI tool.
When to use GitHub Actions?
GitHub Actions is a great choice when your code is already on GitHub and you want to set up CI/CD quickly. However, it's free only if your repository is public, but you will need a paid plan for private repositories. So, if you are looking to use it without cost, GitHub Actions is best suited for public-facing projects.
How do GitHub Actions work?
A GitHub Actions workflow is a file written in YAML format and stored in the /.github/ workflows directory. This workflow file contains one or more jobs. The workflow gets executed when you push code to GitHub (or trigger via any other external event). Once triggered, the jobs defined inside the workflow begin executing. These jobs run in parallel by default. Each job is made up of multiple steps. Each step either runs a shell command or invokes a predefined GitHub action. All steps in a job are executed on a runner, a server environment that GitHub uses to run workflows.
Jenkins Pipelines vs GitHub Actions workflows
Jenkins and GitHub Actions are both CI/CD tools. While Jenkins has been there for a long time, GitHub Actions is relatively new. Jenkins requires setup, whereas GitHub Actions is cloud-based and requires no setup. With Jenkins, we configure pipelines. In GitHub Actions, we define workflows, though the concept is similar. Also, Jenkins pipelines use stages to group steps together, similar to GitHub Actions using jobs. While Jenkins uses declarative code for writing pipelines, GitHub Actions uses YAML specification. In Jenkins, the steps defined in a pipeline are executed on an agent, whereas in GitHub Actions, the jobs are performed on a runner.
Category | Jenkins Pipelines | GitHub Actions Workflows |
Format | declarative pipelines | YAML Specification |
Grouping | Use stages to group steps together. | Use jobs to group steps together. |
Tools | installed using tools keyword, e.g, tools { maven, ...} | pre-installed on the runner |
Executor | agent | runner |
Tool type | Self-hosted | Cloud based |
Setting Up GitHub Actions for my Postman project
For my "API testing using Postman" project, I created a newman-tests.yml file in the /.github/ workflows directory.
The screenshot below shows the newman-tests.yml file used in my project. It defines the workflow steps for running the Postman Collection and generating the Newman Report.
Here is a line-by-line breakdown of the newman-tests.yml file:
Line 1 - The workflow file is assigned a name
Lines 3 to 9 - The workflow is triggered whenever a push or pull request is made to the main branch.
Line 11 – This starts the job part of the workflow.
Line 12 – There is one job in the workflow named run-newman-tests.
Line 13 - This job will be executed on a runner server hosted by GitHub and provisioned with a standard Ubuntu operating system image.
Line 15 - This starts the steps for this job.
Lines 16 and 17 - actions/checkout@v4 is a predefined GitHub Action; its job is to check out the repository code into the GitHub runner.
Lines 19 to 22 - Newman runs on Node.js, so we install version 16 here.
Lines 24 to 27 - Installs Newman globally and the htmlextra reporter to generate an HTML report.
Lines 29 to 36 - Execute the Postman collection using:
An environment file (LMS.postman_environment.json)
Test data file (LMS.json)
Generates an HTML report called newman-report.html
Lines 38 to 42 - Uploads the generated report as an artifact in GitHub. You can download it directly from the Actions tab after completing the run.
Triggering the Workflow and Viewing Reports
Now that the workflow setup is ready, we need to do a code push to the GitHub repository to trigger the workflow. This can be a simple change, like updating a comment. The workflow will start running right away. To see the workflow in action, navigate to the Actions link at the top of the GitHub page.
From here, you can select a run of a workflow and see the jobs that ran as part of the workflow and their statuses. The screenshot below shows the job execution from our “Run Newman Tests” workflow. The generated Newman report is available under Artifacts. You can download it directly by clicking on the name “newman-html-report”.
Also, by clicking on "run-newman-tests", the entire workflow steps can be seen as shown below. This includes all the steps defined in the newman-tests.yml file. Each step - setting up the job, checking out the repository, setting up the Node.js environment, installing Newman, running the Postman collection, and generating and uploading the Newman report — is listed clearly.
By clicking on the ">", the complete log of all the steps can be found. The entire log can also be downloaded by clicking the "Settings" icon in the top right corner.
Conclusion
Using GitHub Actions with Postman and Newman made our testing process faster, more consistent, and automated. It’s an excellent solution for small teams, open-source projects, and hackathons where quick automation is key. Give it a try and see the hidden power of these YAML files.
