CI/CD: Run Test Packs from Jenkins
Install the Shift-Left API Jenkins plugin from its .hpi file, add the Run Test Pack build step to a Freestyle job, gate the build on the pass rate, and publish the JUnit results.
Applies to: Professional, Trial and Enterprise editions (the Public API is not part of the free Citizen Developer edition) · Jenkins Freestyle jobs
Overview
The Shift-Left API Jenkins plugin adds a build step, Shift-Left API Automation Integration: Run Test Pack, to Freestyle jobs. The step signs in to your Shift-Left API server, starts one of your test run packs, waits for that run to finish, applies a quality gate, and can write JUnit XML and a JSON summary into the workspace. If the gate fails, the build is marked FAILURE (or UNSTABLE, if you choose).
The plugin applies the same gate rules as the GitHub Action and the Azure DevOps task.
Note: The plugin is not in the Jenkins Update Center, so you will not find it by searching under Available plugins. You install it from its
.hpifile, as below.
Before you begin
- A test run pack with its environment chosen in the pack. See Test Run Pack Wizard.
- The Public API switched on, with the CI user's role in Allowed Roles, under Settings → Integrations → Public API. See Public API.
- A CI user (email and password), saved in Jenkins as a Username with password credential.
- A server the Jenkins agent can reach. The pack itself runs on your Shift-Left API server.
Step 1 — Install the plugin
- Download the
.hpifrom thejenkinsrelease in Total-Shift-Left/Shift-Left-API-Integrations. You can also build it from the plugin source withmvn -B -ntp verify; the file lands intarget/. - In Jenkins, go to Manage Jenkins → Plugins and open Advanced settings.
- Under Deploy Plugin, click Choose File, select the
.hpi, then Deploy. - Restart Jenkins when prompted, and check that Shift-Left API Automation Integration is listed under Installed plugins.
Step 2 — Add the build step
In a Freestyle job, add the build step Shift-Left API Automation Integration: Run Test Pack and fill in its sections:
| Section | Field | What to enter |
|---|---|---|
| Shift-Left API connection | Server URL | Your server's base URL, with no trailing slash. |
| Tenant ID | Leave empty unless your installation is multi-tenant. | |
| Credentials | The CI user's credential. Click Test Connection to check sign-in and reachability. | |
| Test Pack | Pack ID | Pick the pack from the list, which fills after a successful connection. |
| Execution | Wait for completion | Leave on to wait for the run and grade it. |
| Poll interval (seconds) | Default 10. | |
| Overall timeout (minutes) | Default 60. | |
| Quality Gate | Pass threshold (%) | Minimum pass rate. 0 turns the threshold off. |
| Fail build when any ERROR tests | Fail when any test ends in ERROR, whatever the pass rate. | |
| Build result on gate failure | FAILURE blocks the build; UNSTABLE warns. | |
| Artifacts | Write JSON summary | Optional. A workspace-relative path for the summary. |
| Write JUnit XML | Optional. A workspace-relative path for the JUnit file. |
Step 3 — Publish the results
If you write JUnit XML, add the post-build action Publish JUnit test result report and point it at the same path, so each test shows on the build's Test Result page. After a build, the Shift-Left API Automation Integration link in the build's sidebar shows the run summary and links to the files.
Declarative pipelines (Jenkinsfile)
The plugin provides a Freestyle build step only. In a Jenkinsfile, call the REST API from a shell step instead. Any CI via the REST API has a script you can save as ci/run-shiftleft-pack.sh and call like this:
// Jenkinsfile
pipeline {
agent any
environment {
SHIFTLEFT_URL = 'https://shiftleft.yourcompany.com'
SHIFTLEFT_TEST_PACK_ID = 'your_pack_id'
}
stages {
stage('API Tests') {
steps {
withCredentials([usernamePassword(credentialsId: 'shiftleft-api',
usernameVariable: 'SHIFTLEFT_EMAIL', passwordVariable: 'SHIFTLEFT_PASSWORD')]) {
sh 'bash ci/run-shiftleft-pack.sh'
}
}
}
}
}
Good to know
- The environment comes from the pack. Keep one pack per environment and choose the pack per job or branch.
- One run per pack at a time. A second start of a running pack is refused (HTTP 409).
- It grades the run it started, not the pack's previous run.
- CI sign-ins and CI-started runs are recorded in the audit log.
Related articles
Previous
CI/CD: Run Test Packs from Azure DevOps Pipelines
Product documentation
Next
CI/CD: Any CI via the REST API (GitLab, CircleCI, Bitbucket and others)
Product documentation
Related articles
- Test Execution: Run and Manage Test Run Packs · Product documentation
- Test Run Pack Wizard: Create a Pack · Product documentation
- Manage and Run Execution Packs · Product documentation
- Run Triage: Understand Why a Run Failed · Product documentation
- Test Validity: What a Green Run Leaves Open · Product documentation
- CI/CD: Run Test Packs from GitHub Actions · Product documentation
Next steps
- Getting started · Install + connect your spec
- Configuration fundamentals · Stabilize runs
- Initial configuration · Users, licensing, projects
- Release notes · Updates and fixes
Still stuck?
Tell us what you’re trying to accomplish and we’ll point you to the right setup—installation, auth, or CI/CD wiring.