Generate Newman CI/CD Pipeline Configs for API Testing
Generates copy-paste-ready CI/CD pipeline configs that install Newman and run Postman collections across 5 major platforms.
Why it matters
Automate API testing in continuous integration pipelines by generating ready-to-use CI/CD configurations that install Newman and execute Postman collections as part of automated builds across GitHub Actions, GitLab CI, Jenkins, Azure DevOps, CircleCI, and Bitbucket.
Outcomes
What it gets done
Generate platform-specific CI/CD pipeline YAML or Groovy files with Newman installation and execution steps
Configure test reporters (JUnit XML, HTML) and artifact publishing for CI test result panels
Inject environment variables and secrets securely using platform-native secret management
Set up triggers for push, pull request, schedule, or post-deployment test execution
Install
Add it to your toolbox
Run in your project directory:
curl -fsSL https://spark.entire.vc/get/ag-newman-cicd-integration | bash Overview
Newman CI/CD Integration Generator
This skill generates ready-to-paste CI/CD pipeline configs (GitHub Actions, GitLab CI, Jenkins, Azure DevOps, CircleCI) that install Newman, run a Postman collection with injected secrets, and publish JUnit/HTML test results as CI artifacts. Use it whenever a user wants Newman running Postman collections inside a CI pipeline on one of the five supported platforms, before writing the underlying Postman test assertions.
What it does
Generates complete, copy-paste-ready CI/CD pipeline configurations that install Newman and run Postman collections as part of automated builds, across five platforms: GitHub Actions, GitLab CI, Jenkins (declarative pipeline), Azure DevOps, and CircleCI. Before generating, it collects seven pieces of context: the CI platform, whether the collection is a local repo file or a Postman API URL, whether the environment is a local file or CI-injected secrets, which reporters are needed (JUnit XML for the CI test-results panel, an HTML report, or both), a Node.js version preference (default 18), the trigger (push, pull request, schedule, or post-deploy), and whether a failing test should fail the build (almost always yes). Each platform template installs Newman plus the newman-reporter-htmlextra reporter, runs the collection against an environment file with secrets injected via that platform's own mechanism (GitHub Actions secrets, GitLab CI/CD variables, Jenkins credentials, Azure DevOps pipeline variables, CircleCI env vars), exports both JUnit and HTML reports, and publishes them as CI-native test results and build artifacts (e.g. GitHub's dorny/test-reporter action, Jenkins's junit and publishHTML post-build steps, Azure's PublishTestResults task, CircleCI's store_test_results).
newman run ./collections/my-api.json \
-e ./environments/staging.json \
-r cli,junit,htmlextra \
--reporter-junit-export ./results/junit.xml \
--reporter-htmlextra-export ./results/report.html \
--reporter-htmlextra-title "API Test Results"
Best practices baked into every generated config: never hardcode credentials, always inject secrets through the platform's own variable/secret store and reference them via --env-var "KEY=$SECRET_NAME"; keep collection and environment files in the repo under collections/ and environments/ while .gitignore-ing the results/ output directory; always publish test artifacts with if: always() / when: always so results appear even when Newman exits non-zero; and rely on Newman's own exit code 1 on any test failure to fail the pipeline step automatically, adding --bail if the user wants to stop at the first failure instead of running the full suite. After delivering a config, it offers to hand off to a companion postman-testcase-generator skill (if installed) to generate the Postman test cases behind the CI commands just produced, using that output as its input.
When to use - and when NOT to
Use it whenever a user wants to run Newman in a CI pipeline, integrate Postman collections into automated builds, or set up API tests in GitHub Actions, GitLab CI, Jenkins, Azure DevOps, or CircleCI. It's specifically for generating the pipeline configuration itself, not for writing the underlying Postman test assertions - that's the companion postman-testcase-generator skill's job.
Inputs and outputs
Input is the target CI platform plus the seven context items collected up front (collection source, environment source, reporters, Node version, trigger, fail-on-failure preference). Output is a ready-to-paste pipeline config file for that platform, with secret-injection comments and artifact-publishing steps included.
Integrations
Generates configs for GitHub Actions, GitLab CI, Jenkins, Azure DevOps, and CircleCI, all installing Newman via npm plus the newman-reporter-htmlextra reporter, and optionally hands off to the postman-testcase-generator skill for generating the underlying Postman test cases.
Who it's for
API teams who already have a Postman collection and want it running as an automated CI check - with test results visible in their CI platform's native UI - without hand-writing the pipeline YAML or Groovy themselves.
Source README
Newman CI/CD Integration Generator
When to Use
Use this skill when you need generate ready-to-use CI/CD pipeline configurations that install and run Newman for automated API testing. Use this skill whenever the user wants to run Newman in a CI pipeline, integrate Postman collections into automated builds, set up API tests in GitHub Actions, GitLab CI, Jenkins,...
Generate complete, copy-paste-ready CI/CD pipeline configs that install Newman and run Postman collections as part of automated builds.
What to Collect From the User
Before generating a config, determine:
- CI platform - GitHub Actions, GitLab CI, Jenkins, Azure DevOps, CircleCI, Bitbucket?
- Collection source - local file in repo, or Postman API URL?
- Environment - local env file in repo, or env vars injected by CI secrets?
- Reporters needed - JUnit XML (for CI test results panel), HTML report, or both?
- Node.js version preference (default: 18)
- Trigger - on every push, pull request, schedule, or after deploy?
- Fail build on test failure? - almost always yes; confirm
Platform Templates
GitHub Actions
name: API Tests
on:
push:
branches: [main, develop]
pull_request:
jobs:
api-tests:
runs-on: ubuntu-latest
steps:
- name: Checkout repository
uses: actions/checkout@v4
- name: Set up Node.js
uses: actions/setup-node@v4
with:
node-version: '18'
- name: Install Newman
run: |
npm install -g newman
npm install -g newman-reporter-htmlextra
- name: Run API tests
run: |
newman run ./collections/my-api.json \
-e ./environments/staging.json \
-r cli,junit,htmlextra \
--reporter-junit-export ./results/junit.xml \
--reporter-htmlextra-export ./results/report.html \
--reporter-htmlextra-title "API Test Results"
env:
BASE_URL: ${{ secrets.BASE_URL }}
API_KEY: ${{ secrets.API_KEY }}
- name: Publish test results
uses: dorny/test-reporter@v1
if: always()
with:
name: Newman API Tests
path: results/junit.xml
reporter: java-junit
- name: Upload HTML report
uses: actions/upload-artifact@v4
if: always()
with:
name: api-test-report
path: results/report.html
GitLab CI
stages:
- test
api-tests:
stage: test
image: node:18-alpine
before_script:
- npm install -g newman newman-reporter-htmlextra
script:
- |
newman run ./collections/my-api.json \
-e ./environments/staging.json \
--env-var "BASE_URL=$BASE_URL" \
--env-var "API_KEY=$API_KEY" \
-r cli,junit,htmlextra \
--reporter-junit-export results/junit.xml \
--reporter-htmlextra-export results/report.html
artifacts:
when: always
reports:
junit: results/junit.xml
paths:
- results/report.html
expire_in: 7 days
variables:
BASE_URL: $BASE_URL # Set in GitLab CI/CD > Variables
API_KEY: $API_KEY
Jenkins (Declarative Pipeline)
pipeline {
agent any
tools {
nodejs 'NodeJS-18' // Configure in Global Tool Configuration
}
stages {
stage('Install Newman') {
steps {
sh 'npm install -g newman newman-reporter-htmlextra'
}
}
stage('Run API Tests') {
steps {
sh '''
newman run ./collections/my-api.json \
-e ./environments/staging.json \
-r cli,junit,htmlextra \
--reporter-junit-export results/junit.xml \
--reporter-htmlextra-export results/report.html \
--reporter-htmlextra-title "API Tests - ${BUILD_NUMBER}"
'''
}
}
}
post {
always {
junit 'results/junit.xml'
publishHTML([
allowMissing: false,
alwaysLinkToLastBuild: true,
keepAll: true,
reportDir: 'results',
reportFiles: 'report.html',
reportName: 'Newman API Test Report'
])
}
}
}
Azure DevOps
trigger:
branches:
include:
- main
pool:
vmImage: 'ubuntu-latest'
steps:
- task: NodeTool@0
inputs:
versionSpec: '18.x'
displayName: 'Set up Node.js'
- script: |
npm install -g newman newman-reporter-htmlextra
displayName: 'Install Newman'
- script: |
newman run ./collections/my-api.json \
-e ./environments/staging.json \
--env-var "API_KEY=$(API_KEY)" \
-r cli,junit,htmlextra \
--reporter-junit-export $(System.DefaultWorkingDirectory)/results/junit.xml \
--reporter-htmlextra-export $(System.DefaultWorkingDirectory)/results/report.html
displayName: 'Run API Tests'
env:
API_KEY: $(API_KEY) # Set in Pipeline > Variables
- task: PublishTestResults@2
condition: always()
inputs:
testResultsFormat: 'JUnit'
testResultsFiles: 'results/junit.xml'
testRunTitle: 'Newman API Tests'
- task: PublishBuildArtifacts@1
condition: always()
inputs:
PathtoPublish: 'results/report.html'
ArtifactName: 'api-test-report'
CircleCI
version: 2.1
jobs:
api-tests:
docker:
- image: cimg/node:18.0
steps:
- checkout
- run:
name: Install Newman
command: npm install -g newman newman-reporter-htmlextra
- run:
name: Run API Tests
command: |
mkdir -p results
newman run ./collections/my-api.json \
-e ./environments/staging.json \
--env-var "API_KEY=$API_KEY" \
-r cli,junit,htmlextra \
--reporter-junit-export results/junit.xml \
--reporter-htmlextra-export results/report.html
- store_test_results:
path: results
- store_artifacts:
path: results/report.html
workflows:
test:
jobs:
- api-tests
Best Practices
Secrets - never hardcode credentials
Always inject sensitive values as CI environment variables/secrets:
- GitHub:
Settings > Secrets and Variables > Actions - GitLab:
Settings > CI/CD > Variables - Jenkins:
Manage Jenkins > Credentials - Azure DevOps:
Pipelines > Variables
Reference in Newman via --env-var "KEY=$SECRET_NAME" or pre-set in the environment file.
Store collection and environment files in the repo
/
├── collections/
│ └── my-api.json
├── environments/
│ ├── staging.json
│ └── prod.json
└── results/ ← gitignored, created by Newman
Add results/ to .gitignore.
Always use if: always() / when: always
Ensure test result artifacts are published even when Newman exits with a failure code.
Exit codes
Newman exits with code 1 if any tests fail - this automatically fails the pipeline step. Use --bail if you want to stop on the first failure rather than running all tests.
How to Generate Configs
- Confirm the CI platform and tailor the exact syntax
- Use the correct secret/variable injection syntax for that platform
- Include artifact publishing steps so test results appear in the CI UI
- Add comments explaining secrets that need to be configured
- Keep environment files in the repo (without secrets); inject sensitive values via CI vars
After Completing the Newman CICD output
Once the Newman CICD output is delivered, ask the user:
"Would you like me to generate Postman Test Cases for these commands? (yes/no)"
If the user says yes:
- Check if the postman-testcase-generator skill is available in the installed skills list
- If the skill is available:
- Read and follow the instructions in the postman-testcase-generator skill
- Use the CICD command output above as the input
- If the skill is NOT available:
- Inform the user: "It looks like the postman-testcase-generator skill isn't installed.
You can install it and re-run.
- Inform the user: "It looks like the postman-testcase-generator skill isn't installed.
If the user says no:
- End the task here
Limitations
- Use this skill only when the task clearly matches its upstream source and local project context.
- Verify commands, generated code, dependencies, credentials, and external service behavior before applying changes.
- Do not treat examples as a substitute for environment-specific tests, security review, or user approval for destructive or costly actions.
FAQ
Common questions
Discussion
Questions & comments · 0
Sign In Sign in to leave a comment.