Generate Newman CI/CD Pipeline Configs for API Testing

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.

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.

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.

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.

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.