> For the complete documentation index, see [llms.txt](https://docs.nullify.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.nullify.ai/connectors/jenkins.md).

# Jenkins

## Overview

The Jenkins connector gives Nullify eyes on your CI. When Nullify opens an autofix pull request, your Jenkins job runs against it like any other change — and if that build fails, Nullify reads the failure and fixes its own work before a human ever has to look. Once connected, Nullify can:

* **See your Jenkins builds** on the pull requests it opens, including pass/fail status.
* **Read the console output of a failed build** straight from the Jenkins API to understand *why* CI broke.
* **Iterate on the fix automatically**, feeding the real CI failure back to the autofix agent until the build is green.

The result is an autofix loop that's accountable to your actual pipeline — linting, tests, type checks, build steps and all — not just to Nullify's own checks. Teams that run Jenkins for CI alongside GitHub for source control get fixes that are already CI-clean by the time they land in review.

## How it works

Nullify never sits in the critical path of your pipeline and never changes how your builds run. It watches, reads, and iterates:

1. **Nullify pushes an autofix commit** to a pull request.
2. **Jenkins runs your job** against that commit, exactly as it would for any developer push.
3. **Jenkins reports the result to GitHub** as a commit status (this is Jenkins' standard GitHub integration — for example the GitHub Branch Source plugin, which posts a `continuous-integration/jenkins/…` status).
4. **Nullify detects the status** through its GitHub App — including when the build fails.
5. **Nullify fetches the failed build's console log** from the Jenkins API using your connected URL, username, and token. The build's console URL is taken from the status event and **pinned to your configured Jenkins host** before any request is made.
6. **The autofix agent iterates**, using the real failure output as context, and pushes a new commit — which kicks off the loop again until CI is green.

```
Autofix commit ─▶ Jenkins job runs ─▶ Build fails
                                          │
                  GitHub commit status ◀──┘
                           │
                  Nullify detects failure
                           │
               Fetches Jenkins console log ─▶ Agent iterates ─▶ new commit ↺
```

The integration is **read-only on your CI**: Nullify reads build status and console output. It does not trigger, cancel, or modify your jobs, and it does not write anything back to Jenkins.

{% hint style="info" %}
**How Nullify recognises a Jenkins build.** Nullify matches the GitHub commit-status context (`continuous-integration/jenkins…`) reported by your Jenkins GitHub integration. If your jobs publish statuses under a different context string, let your Nullify representative know so detection can be confirmed.
{% endhint %}

## Prerequisites

Before you start, make sure you have:

* A **Jenkins instance** reachable over HTTPS, running at least one job against your pull requests. The instance must be reachable from Nullify — Nullify rejects URLs that resolve to internal, loopback, or otherwise private addresses.
* Your Jenkins instance **posting commit statuses to GitHub** (for example via the GitHub Branch Source or GitHub plugin), so build results reach GitHub — and therefore Nullify.
* **GitHub already connected to Nullify.** Jenkins layers on top of the GitHub connection; it is not a standalone source-control integration.
* A **Jenkins user and API token** that can read the relevant jobs' console output. Nullify authenticates to the Jenkins API with HTTP basic auth using this username and token.

{% hint style="info" %}
**Use a dedicated service account for the API token, not a personal one.** Create a Jenkins user that exists only for Nullify, grant it read access to the relevant jobs, and mint the API token from that account (**Manage Jenkins → Users → *****that user***** → Configure → API Token**). This keeps the integration alive when people change teams or leave, scopes Nullify's access to exactly what that user can see, and makes the token easy to audit and rotate.
{% endhint %}

## Configuration

Configure Jenkins through the Nullify dashboard (**Configure → Connectors → Jenkins**) or the admin API. The credentials you provide are stored encrypted in AWS SSM Parameter Store — the API token as a `SecureString`; Nullify never returns the token back to you after it is saved.

### Connect via the admin API

Store the URL, username, and API token:

```http
POST /admin/integrations/jenkins/token
Content-Type: application/json

{
  "url": "https://jenkins.yourcompany.com",
  "username": "nullify-ci",
  "apiToken": "<jenkins-api-token>"
}
```

All three fields are required. The `url` must be a valid `http`/`https` URL and must not target an internal or loopback host.

Check whether a Jenkins integration is configured:

```http
GET /admin/integrations/jenkins
```

```json
{ "configured": true }
```

Remove the integration (deletes the stored URL, username, and token):

```http
DELETE /admin/integrations/jenkins
```

{% hint style="info" %}
Re-posting to `/admin/integrations/jenkins/token` overwrites the stored URL, username, and token in place — that's also how you **rotate** the API token. There's no downtime: Nullify uses the new credentials the next time it reads a build.
{% endhint %}

## What data flows

| Direction             | Data                                                                                                                                                                     |
| --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **GitHub → Nullify**  | Commit-status events for Jenkins builds on Nullify's pull requests (pass/fail and the build's target URL), via the Nullify GitHub App.                                   |
| **Jenkins → Nullify** | The plain-text console log of a **failed** build, fetched on demand from `…/consoleText` on your configured Jenkins host. Log reads are capped in size and time-bounded. |
| **Nullify → Jenkins** | Nothing. Nullify only issues authenticated read requests for console output; it never triggers, cancels, or configures jobs.                                             |

## Removing the integration

Delete the connector from **Configure → Connectors → Jenkins**, or call `DELETE /admin/integrations/jenkins`. This removes your stored URL, username, and token from Nullify. Your Jenkins jobs are untouched and keep running exactly as before — disconnecting only stops Nullify from reading build status and console output.