> 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.

Jenkins connection availability is controlled per tenant. If its settings panel is absent, contact Nullify to confirm enablement before creating credentials. The build-log integration supplements an existing GitHub connection.