> ## Documentation Index
> Fetch the complete documentation index at: /docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Enterprise CI and Java clients

> Configure a single GitHub Enterprise Server deployment and publish portable JUnit reports in Bitbucket or Jenkins.

## GitHub Enterprise Server

Set `GITHUB_SERVER_URL=https://git.example.internal` in the EvalGate deployment. REST uses `/api/v3`, GraphQL uses `/api/graphql`, and GitHub App authorization and installation links use that same server. Leave it unset for GitHub.com.

A deployment targets **one GitHub server**. Its App ID, private key, webhook secret and App OAuth credentials must belong to that server. A deployment cannot mix GitHub.com and GHES installations. Webhook signatures are verified using the configured secret as before. TLS must use HTTPS; URL credentials, query strings and path prefixes are refused.

Imported Actions release evidence must use that same configured HTTPS origin (including its port), the exact connected repository and a canonical `/owner/repo/actions/runs/ID` URL. Other hosts, credentials, query strings, fragments and arbitrary path suffixes are refused before contacting GitHub. Recorded release links use the configured server too.

When running TypeScript or Python `proof` commands outside Actions, set `GITHUB_SERVER_URL` locally to the same origin as your EvalGate deployment so imported GHES runs appear in proof suggestions. GitHub Actions supplies this variable in its runner environment.

This setting selects the GitHub App integration server. Application sign-in is configured separately through OAuth or organization SSO. Source tests prove endpoint selection. Acceptance against your GHES version, network policy and App installation still needs a configured test server.

## Bitbucket Pipelines and Jenkins

The CLI captures Bitbucket build, repository, commit, branch and pull request context from `BITBUCKET_*` variables. Jenkins capture uses `JENKINS_URL`, `BUILD_URL`, `GIT_COMMIT`, `GIT_URL` and `BRANCH_NAME`/`CHANGE_ID`. GitLab and CircleCI use their own provider variables.

Use `evalgate check --format junit` or `evalgate ci --format junit` and write stdout to a report file. JUnit output preserves the command's gate exit status: absent evidence is an error, not a pass. XML text is escaped and transfer redaction applies. Human diagnostics go to stderr for `ci`.

```yaml theme={null}
# Bitbucket Pipelines step (after installing the source candidate)
script:
  - mkdir -p test-results
  - evalgate ci --format junit > test-results/evalgate.xml
```

```groovy theme={null}
// Jenkins pipeline: preserve the command result and publish the report.
pipeline {
  agent any
  stages {
    stage('EvalGate') {
      steps { sh 'mkdir -p test-results; evalgate ci --format junit > test-results/evalgate.xml' }
      post { always { junit 'test-results/evalgate.xml' } }
    }
  }
}
```

Bitbucket Code Insights and native pull request checks are not implemented. JUnit is the supported report integration; test it in your own CI workspace before treating it as a production release receipt.

## Python manifest and generation commands

The Python source SDK includes `evals validate|plan|apply|diff|gate` with the same manifest API bodies as TypeScript. YAML is loaded with `yaml.safe_load`; install `evalgate-sdk[yaml]` for YAML input. JSON manifests work without the extra. The command uses the shared credential and base-URL resolver.

`evalgate generate` natively calls OpenAI or Anthropic using the selected provider's environment credential and writes JSONL cases for review. It does not require Node. Generated cases are proposals for review, not validated ground truth.

`evalgate import inspect` recomputes supported external optimization observations locally and retains investigation-only authority. Native `evalgate proof` commands inspect or submit the same server-validated proof transitions as TypeScript; they cannot invent human approval or release authority.

## Java 17 source SDK

`src/packages/sdk-java` contains the generated Java REST client with Java 17 HTTP transport, Jackson, and record models. `generation.json` pins every operation and the OpenAPI source digest. Compile and run mock-server smoke tests with `mvn -q test`. This is source support; it does not claim a published Maven package or live enterprise acceptance.

Heterogeneous unions remain explicit JSON nodes. Polymorphic default typing is disabled; nullable values use boxed references. Credentials stay in headers, redirects are disabled and mutations are never automatically retried.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.