Ellipse Gradient for Header

Jenkins Integration Guide

Integrate Jenkins with enterprise systems through its remote access API, authenticated build triggers, queue and build polling, artifacts, and plugin-dependent webhook notifications.

Jenkins integration options at a glance

Jenkins provides a remote access API for reading jobs, builds, queues, nodes, views, console output, and artifacts, as well as starting jobs and supplying build parameters. Responses can commonly be requested in JSON or XML. Build execution is asynchronous: a trigger normally returns a queue reference that must be followed until a build is assigned and reaches a terminal state. Webhook-style notifications are available through selected plugins, but coverage and payloads vary by installation. Martini can authenticate with a Jenkins username and API token, orchestrate triggers and polling, receive configured callbacks, transform Jenkins data, and route results to enterprise applications or databases.

Integration pointSupported by Jenkins?Common use casesHow Martini supports it
REST-style remote access APIYesRead Jobs, Builds, Queues, Nodes, Views, console output, and selected user information; start builds and invoke parameterized builds.Martini can consume Jenkins HTTP endpoints, map JSON or XML responses, and expose reusable APIs or workflows around Jenkins operations.
Webhooks / outbound callbacksLimitedSource-control triggers, generic webhook triggers, and selected build-result notifications can be provided by installed plugins.Martini can expose an API endpoint to receive configured callbacks and validate, transform, route, and deduplicate plugin-specific payloads.
Bulk / async / batch APIsLimitedJenkins supports asynchronous build execution through queue items and subsequent polling, but no general-purpose bulk CRUD API was confirmed.Martini can capture queue references, poll with backoff, enforce timeouts, and process multiple jobs with controlled concurrency.
File / artifact accessLimitedCompleted builds can expose console output and downloadable artifacts, subject to job configuration and retention policies.Martini can make authenticated requests for selected artifact metadata or files, validate build state, and pass large artifacts by reference where appropriate.
AuthenticationYesJenkins supports username and API token with HTTP Basic Authentication, configurable security realms, authorization strategies, and CSRF protection for many state-changing requests.Martini can store the technical user's credentials in secure environment configuration or secrets and apply least-privilege access to HTTP calls.
CLI and administrative interfacesLimitedJenkins provides CLI and administrative interfaces, primarily for administration rather than standard application integration.Martini integrations should prefer documented HTTP APIs; custom execution is possible only when the deployment explicitly supports and secures the required interface.
Database accessNoJenkins does not document a supported direct database integration API for operational data.Martini should use Jenkins remote APIs or plugin-provided endpoints rather than reading Jenkins internal files or storage directly.

How Jenkins exposes data and business events

Jenkins REST APIs

Jenkins' documented remote access API exposes HTTP endpoints for Jobs, Builds, Queues, Nodes, Views, console output, artifacts, and selected plugin resources. Responses can commonly be requested in JSON or XML, and build endpoints can accept parameters.

Martini implementation pattern

Martini implementation pattern: a workflow authenticates with a Jenkins username and API token, calls the required endpoint, validates the response, and maps Jenkins data into a canonical model or downstream request. For state-changing calls, the workflow accounts for CSRF behavior and records the request correlation ID.

Implementation sequence

Authenticate with a least-privilege Jenkins technical user
Resolve the encoded job or folder path
Submit the build or parameterized-build request
Capture the returned queue reference
Retrieve queue and build status
Map the terminal result to the target system

Jenkins queues and asynchronous builds

Starting a Jenkins build commonly creates a queue item before an executable and build number exist. Queue delays can result from unavailable agents, quiet periods, locks, throttling, or other plugins.

Martini implementation pattern

Martini implementation pattern: the workflow treats an accepted trigger as asynchronous, polls the queue with exponential backoff, applies a maximum wait, then polls the assigned Build until it reaches a terminal result. It separates transport success from actual build success.

Implementation sequence

Submit the authenticated build request
Store the queue item URL or identifier
Poll until an executable is assigned or the item is cancelled
Poll the resulting Build until a terminal result
Apply timeout and cancellation rules
Persist the build URL and outcome

Jenkins webhook-style notifications

Jenkins can receive or send webhook-style notifications through selected source-control, generic webhook, and notification plugins. Event coverage, authentication, payload formats, and endpoint behavior depend on the installed plugin and version; Jenkins core has no universal event bus for every object.

Martini implementation pattern

Martini implementation pattern: Martini exposes a controlled API endpoint when a configured Jenkins plugin sends callbacks, validates the plugin-specific payload and shared secret or authentication arrangement, then normalizes the event. API polling remains the fallback for plugin-independent build monitoring.

Implementation sequence

Configure the Jenkins plugin endpoint and event scope
Receive the callback at a Martini API endpoint
Validate authentication, payload shape, and event type
Derive the job, build, or correlation identifier
Retrieve authoritative Jenkins status when needed
Apply idempotency and route the normalized event

Common Jenkins integration patterns

Pattern 1: Orchestrate a release Pipeline

When to use this pattern

Use this pattern when a business, release-management, or change system needs to request a Jenkins deployment and receive a controlled outcome. Martini validates the environment, version, authorization context, and correlation ID before Jenkins is invoked.

Integration direction
Release-management system
Martini
Jenkins
Example Mapping
Jenkins FieldCanonical FieldTarget Field
releaseIdcorrelationIdRELEASE_ID
versionartifactVersionVERSION
environmentdeploymentEnvironmentENVIRONMENT
requestedByrequesterREQUESTED_BY
Martini implementation pattern

A Martini API accepts the release request and starts the configured Jenkins Pipeline with mapped parameters. The workflow follows the queue, polls the Build, distinguishes SUCCESS from FAILURE, UNSTABLE, ABORTED, and still-running states, and updates the originating system. Before triggering, it can check for a matching queued or running build to reduce duplicates.

Martini capabilities used
  • API exposure
  • API consumption
  • workflows
  • data mapping
  • business rules
  • asynchronous orchestration
  • error handling

Pattern 2: Control source-control-triggered builds

When to use this pattern

Use this pattern when multiple repositories, branches, or Jenkins instances require consistent validation and routing before a build starts. It is suitable when source-control webhook payloads must be filtered by repository, event type, branch, or commit.

Integration direction
GitHub or GitLab
Martini
Jenkins
Example Mapping
Jenkins FieldCanonical FieldTarget Field
repository.full_namerepositoryREPOSITORY
refbranchBRANCH
aftercommitShaCOMMIT_SHA
pull_request.numberchangeNumberCHANGE_NUMBER
Martini implementation pattern

Martini receives the source-control event, validates the payload and configured repository allowlist, selects a Jenkins job, and submits a parameterized build. It passes the commit SHA and event ID as correlation values, then polls Jenkins or receives a configured callback. Invalid events are rejected without triggering a build, while transient Jenkins failures follow retry rules.

Martini capabilities used
  • API exposure
  • webhook consumption
  • workflows
  • validation
  • routing
  • data mapping
  • retry handling

Pattern 3: Synchronize Jenkins build results

When to use this pattern

Use this pattern when a reporting, service-management, release, or collaboration system needs a reliable view of Jenkins execution status. It is useful when the Jenkins installation does not provide a suitable notification plugin or when periodic reconciliation is required.

Integration direction
Jenkins
Martini
Jira or reporting database
Example Mapping
Jenkins FieldCanonical FieldTarget Field
fullDisplayNamebuildNameBUILD_NAME
numberbuildNumberBUILD_NUMBER
resultbuildStatusSTATUS
timestampstartedAtSTARTED_AT
Martini implementation pattern

A scheduled Martini workflow retrieves selected Jobs and recent Builds with narrow response fields, maps stable identifiers and status values, and upserts them into the target system. It uses the Jenkins full build URL or job-and-build number for idempotency, limits concurrency, and records API or authorization failures for retry and reconciliation.

Martini capabilities used
  • scheduled workflows
  • API consumption
  • mapping and transformation
  • upsert logic
  • idempotency
  • monitoring
  • error handling

Pattern 4: Handoff successful build artifacts

When to use this pattern

Use this pattern when a successful Jenkins Build produces an artifact that must be passed to a deployment service, repository, notification process, or release record. The workflow should not assume that every job produces artifacts or that retained artifacts are available indefinitely.

Integration direction
Jenkins
Martini
Docker registry or deployment API
Example Mapping
Jenkins FieldCanonical FieldTarget Field
artifact.fileNameartifactNameARTIFACT_NAME
artifact.relativePathartifactReferenceARTIFACT_REFERENCE
build.numberbuildNumberBUILD_NUMBER
build.resultqualityStatusBUILD_STATUS
Martini implementation pattern

Martini confirms that the Build succeeded, retrieves selected artifact metadata or content through authenticated Jenkins requests, validates the expected version or checksum when available, and sends a reference or payload to the target API. Size, timeout, retention, missing-artifact, and downstream rejection branches are handled explicitly.

Martini capabilities used
  • workflows
  • API consumption
  • file handling
  • validation
  • mapping
  • business rules
  • error handling

Applications commonly integrated with Jenkins

Jenkins is commonly connected to source-control, issue-management, collaboration, quality, container, and deployment platforms. The exact operations depend on installed Jenkins plugins, job definitions, credentials, and the capabilities of the connected application. Martini can provide a controlled orchestration layer around these integrations rather than depending on undocumented plugin behavior.

Application Scenario Direction Martini Pattern
GitHub Trigger Jenkins jobs from repository activity, associate builds with commits or pull requests, and publish build status. GitHub → Martini → Jenkins Martini receives or consumes a GitHub event, validates the repository and branch, maps the commit or pull-request context to Jenkins build parameters, and starts the appropriate job. A follow-up workflow polls the queue and build or routes the result back to GitHub through its API.
GitLab Start Jenkins jobs from GitLab repository events and report build or deployment outcomes to merge-request workflows. GitLab → Martini → Jenkins A Martini API receives the GitLab event, applies repository and branch routing rules, and calls the Jenkins parameterized-build endpoint. Martini tracks the queue item and terminal build result, then can update GitLab using a separate authenticated API call.
Bitbucket Connect repository activity with Jenkins builds and associate results with commits or pull requests. Bitbucket → Martini → Jenkins Martini validates Bitbucket event payloads, resolves the configured Jenkins job path, and submits a build with a stable commit or correlation parameter. It polls Jenkins and maps the outcome to a Bitbucket status operation where the relevant integration is configured.
Jira Link builds and deployments to issues, releases, change records, or delivery status. Jira → Martini → Jenkins Martini accepts a Jira release or change request, validates the target environment and version, starts a Jenkins Pipeline with those values, and synchronizes queue, build, and artifact references back to Jira or an intermediate release record.
Slack Send build, deployment, and failure notifications to operational or delivery channels. Jenkins → Martini → Slack Martini polls Jenkins or receives a configured plugin callback, normalizes the build result and link, applies notification rules, and sends a concise message to Slack. Duplicate notifications can be suppressed using the Jenkins full build URL as the event key.
Docker Coordinate image builds, registry publishing, and promotion workflows after successful Jenkins executions. Jenkins → Martini → Docker Martini validates the Jenkins build result, extracts image or artifact metadata exposed by the job, and passes a version or digest to Docker or a registry API. Large artifacts are preferably referenced rather than copied through every workflow step.
SonarQube Use code-quality analysis and quality-gate outcomes to control release promotion. Jenkins → Martini → SonarQube After Jenkins starts the analysis job, Martini tracks the build and, where exposed by the configured integration, retrieves the quality result. Business rules prevent promotion when the quality gate fails or is unavailable and persist the decision with the build correlation ID.
Kubernetes Coordinate cloud-native deployments or Jenkins agent-related workflows with deployment records and release processes. Jenkins → Martini → Kubernetes Martini starts or monitors the Jenkins deployment pipeline, validates environment and image metadata, and invokes a Kubernetes API or downstream deployment service only after the required build and quality checks succeed. Timeout and rollback handling remain explicit workflow branches.

How to build a Jenkins integration in Martini

Objective

Establish authenticated access to the target Jenkins instance using a dedicated technical user, API token, HTTPS, and the minimum Jenkins permissions required by the workflow.

Instructions in Martini

  • Create a Jenkins service account with only required job, build, queue, node, or artifact permissions
  • Store the username and API token in Martini secrets or secure environment configuration
  • Configure the Jenkins base URL and verify certificate and authentication behavior
  • Confirm whether the target instance requires a CSRF crumb for the selected state-changing requests

Objective

Select the event, API request, or schedule that should initiate the integration and decide whether Jenkins callbacks are reliable enough for the installation.

Instructions in Martini

  • Use a Martini API endpoint for release requests or configured Jenkins-compatible callbacks
  • Use a source-control event only when the relevant Jenkins plugin and payload are confirmed
  • Use a scheduled workflow for reconciliation, queue monitoring, or plugin-independent build status
  • Define correlation, repository, branch, and environment inputs before triggering a job

Objective

Call the documented remote access API to start jobs or retrieve Jobs, Queues, Builds, Nodes, Views, console output, and artifacts as required.

Instructions in Martini

  • Resolve folder, multibranch, and special-character job paths safely
  • Request narrow JSON or XML responses where supported
  • Capture queue references returned by asynchronous build triggers
  • Poll queues and Builds with backoff, bounded duration, and controlled concurrency

Objective

Use a Martini workflow to separate transport handling, Jenkins execution state, business decisions, and downstream updates.

Instructions in Martini

  • Distinguish accepted, queued, running, successful, unstable, failed, aborted, and timed-out states
  • Apply environment, branch, quality, approval, and duplicate-build rules
  • Route transient HTTP failures separately from authorization, invalid-path, parameter, and build failures
  • Persist correlation IDs, Jenkins URLs, queue identifiers, and build numbers

Objective

Convert Jenkins JSON or XML and plugin-specific callback payloads into a stable canonical model for enterprise systems.

Instructions in Martini

  • Map job URL, build number, result, timestamp, duration, display URL, and artifact references
  • Treat plugin-specific fields as optional unless the installation contract guarantees them
  • Normalize Jenkins result values for the target application
  • Use JSON or XML transformation and validation appropriate to the endpoint

Objective

Deliver validated Jenkins status, artifact references, or notifications to the target application without confusing trigger acceptance with build success.

Instructions in Martini

  • Update the release, issue, reporting, or notification system only after the relevant Jenkins state is known
  • Pass large artifacts by reference where possible
  • Use idempotent upsert behavior based on the full build URL or a business correlation ID
  • Record missing artifacts and downstream rejections as explicit outcomes

Common Jenkins data objects used in integrations

ObjectTypical UseCommon target systemsMartini handling
JobsRepresent Freestyle projects, Pipeline jobs, multibranch projects, folders, and other buildable project types.GitHub, GitLab, Jira, release-management platforms, reporting databasesMartini retrieves stable job URLs and names, resolves nested folder paths, applies routing rules, and stores identifiers needed for later build operations.
BuildsRepresent individual job executions with build number, result, duration, timestamp, URL, and console output.Jira, Slack, GitHub, GitLab, service-management platforms, reporting storesMartini polls or receives notifications, distinguishes queued, running, successful, unstable, failed, and aborted states, and uses the full build URL or job-and-build number as an idempotency key.
PipelinesDefine and execute delivery automation, commonly represented by Pipeline jobs and their Builds.Release-management systems, Jira, Kubernetes, Docker registries, deployment APIsMartini validates release inputs, maps environment and version parameters, starts the Pipeline job, and controls downstream promotion based on terminal build results.
Nodes / agentsProvide machines or execution agents on which Jenkins tasks run.Operations platforms, capacity reports, infrastructure management systemsMartini can retrieve exposed node data for monitoring or reporting, while avoiding assumptions about plugin-specific agent fields.
ArtifactsFiles produced by completed Builds and made available for download.Docker registries, deployment platforms, artifact repositories, notification or release systemsMartini verifies build success and artifact retention, retrieves selected files or metadata, and applies size, timeout, checksum, and reference-versus-copy rules.
QueuesTrack pending build or task requests before an executor and build number are assigned.Release-management platforms, dashboards, operational storesMartini captures the queue reference after triggering a build, polls until assignment or cancellation, and routes timeout, blocked, or cancelled states separately.

Authentication and security considerations

Use least-privilege Jenkins access

Use a dedicated Jenkins technical user with an API token and only the permissions required to read jobs, trigger builds, monitor queues and builds, or retrieve artifacts. Do not use an administrative account for routine Martini workflows.

Protect credentials and requests

  • Store the username and API token in Martini secrets or secure environment configuration.
  • Use HTTPS and validate certificates in production.
  • Verify CSRF crumb behavior for state-changing requests on the target Jenkins instance.
  • Do not expose broad Jenkins administrative endpoints through a public Martini API.
  • Review plugin-specific authentication and callback requirements separately.

Operational considerations for Jenkins integrations

Asynchronous execution

A successful build trigger normally means that Jenkins accepted a request, not that the Build succeeded. Capture the queue reference, poll with exponential backoff, enforce a maximum duration, and evaluate terminal states such as SUCCESS, FAILURE, UNSTABLE, ABORTED, and NOT_BUILT.

Paths, payloads, and load

  • URL-encode job names and support nested folder and multibranch paths.
  • Use narrow tree or depth responses where supported and avoid repeatedly retrieving large console outputs.
  • Control polling concurrency because Jenkins has no uniform rate-limit contract and excessive polling can consume controller resources.
  • Use stable build URLs or business correlation IDs for idempotency and duplicate prevention.

Plugins, retention, and change

  • Record the Jenkins version, job type, plugin names, and plugin versions used by the integration.
  • Treat plugin-specific fields and webhook payloads as optional unless covered by an explicit contract.
  • Check artifact retention before downloading files and prefer references for large artifacts.
  • Test upgrades, authorization changes, queue delays, controller restarts, malformed callbacks, and schema variations.

Why use Martini instead of scripts or point-to-point integrations?

Coordinate more than an HTTP call

Scripts can invoke a Jenkins endpoint, but enterprise integrations also need validation, routing, asynchronous queue handling, status normalization, idempotency, retries, downstream updates, and operational visibility. Martini provides a maintainable workflow layer for these concerns.

Reuse integration behavior

Martini can expose controlled APIs for release requests, consume Jenkins REST endpoints, receive configured callbacks, transform JSON or XML, and apply business rules without embedding orchestration in individual applications.

Operate with clearer controls

  • Centralize secrets and environment-specific configuration.
  • Separate transient transport failures from Jenkins execution failures.
  • Persist correlation IDs, queue references, build URLs, and outcomes.
  • Reuse the same orchestration approach across Jenkins instances and downstream systems while keeping plugin-specific behavior explicit.

Frequently asked questions

How can Jenkins be integrated with enterprise systems?

Jenkins can be integrated through its remote access API using authenticated HTTP requests. Enterprise workflows can read Jobs, Builds, Queues, Nodes, Views, console output, and artifacts, start jobs with parameters, and poll asynchronous executions. Selected plugins can add webhook-style triggers or notifications, but their event coverage and payloads depend on the Jenkins installation.

Can Martini integrate with Jenkins?

Yes. Martini can consume the Jenkins remote access API, start jobs and Pipelines, follow queue and Build status, retrieve permitted artifacts, and expose an API endpoint for configured Jenkins plugin callbacks. Martini can map Jenkins responses into downstream APIs, databases, notifications, or release records.

Do I need a connector to integrate Jenkins with Martini?

No dedicated Jenkins connector is required or documented. Martini can integrate with Jenkins using its native remote access API, username and API token authentication, asynchronous queue and Build endpoints, artifact endpoints, and plugin-dependent webhook or callback mechanisms.

Is there any extra Lonti cost to integrate Jenkins with Martini?

Lonti does not charge an additional per-connector or per-vendor fee to integrate Jenkins with Martini. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Jenkins-related infrastructure, cloud services, plugins, or other third-party systems depending on subscriptions, usage, and deployment model.

Which Jenkins integration methods should an enterprise use?

The primary method is Jenkins' documented remote access API, accessed through HTTP with an API token. Use parameterized build endpoints to start jobs, queue and Build endpoints to monitor execution, and artifact endpoints when retained files are required. Plugin-specific webhooks or callbacks can supplement polling when their behavior is confirmed.

Are Jenkins webhooks or events available?

Webhook-style notifications are available through selected source-control, generic webhook, and notification plugins, but Jenkins core does not provide a universal outbound event bus for every Job, Build, Queue, Node, User, or Artifact event. Martini can receive configured callbacks and validate their payloads; scheduled API polling is the more generally applicable fallback.

How does Martini synchronize Jenkins build status?

A Martini workflow can trigger a Build, capture its queue reference, poll until an executable and build number are assigned, and continue polling until a terminal result is available. It can then map status, timing, URLs, and artifact references into a target system using an idempotency key such as the full build URL or job-and-build number.

How does Martini handle Jenkins errors, retries, and duplicate builds?

Martini can distinguish transient HTTP or availability failures from authorization errors, invalid job paths, rejected parameters, queue cancellation, timeouts, and actual Build failures. Exponential backoff and bounded retries can be applied to polling. A stable release ID, commit SHA, or deployment request ID can be passed as a build parameter and checked before triggering another Build.

Related Martini documentation

Jenkins APIs

Webhooks

Workflows

Security

Operations

Integrate Jenkins with Martini

Use Martini to connect Jenkins build automation with release, source-control, quality, deployment, and operational systems through governed APIs and resilient workflows.

EXPLORE MARTINI
BOOK A DEMO