Blog

AI for CI/CD Pipeline Debugging with Jenkins and Skyflo

How Skyflo's Jenkins MCP tools work — from natural language build triggering to log analysis, parameter-aware job management, and cross-tool debugging.

8 min read
jenkinsci-cdautomationtroubleshootingintegrations

The Jenkins Debugging Problem

Jenkins is the most widely deployed CI/CD server. It's also the one where debugging takes the longest, not because Jenkins is bad, but because the information you need is spread across multiple layers:

  • Build logs: Often thousands of lines. The relevant error is on line 847 of 1,200. You scroll, ctrl+F for "ERROR", and hope.
  • Parameters: The build used parameters from upstream jobs, environment variables, and default values. Figuring out which parameter caused the failure means cross-referencing the build config, the Jenkinsfile, and the upstream trigger.
  • SCM context: The build pulled a specific commit. Did that commit introduce the failure? You need to check the diff, the PR, and the test results, all in a different tool.
  • Infrastructure state: The build deployed to a Kubernetes cluster. Did the deployment succeed? Are the pods healthy? You need to switch to kubectl to find out.

This is the exact problem agentic AI is built for: multi-tool correlation, intelligent log analysis, and structured follow-up actions. Skyflo's Jenkins MCP tools bring Jenkins into the same operational context as your Kubernetes cluster, Helm releases, and observability stack.

Jenkins MCP Tools: What's Available

Skyflo's Jenkins MCP server exposes a set of typed tools that the AI agent can call. Each tool has a defined schema, input validation, and structured output. No screen-scraping Jenkins's web UI or parsing raw HTML.

Tooljenkins.list_jobs
PurposeList all jobs with health status and build info
Operation TypeRead
Tooljenkins.get_job_info
PurposeDetailed job config: parameters, health, last builds
Operation TypeRead
Tooljenkins.get_build_info
PurposeBuild details: status, duration, parameters used, artifacts
Operation TypeRead
Tooljenkins.get_build_log
PurposeFull or partial console output for a build
Operation TypeRead
Tooljenkins.build_job
PurposeTrigger a new build with parameters
Operation TypeWrite (requires approval)
Tooljenkins.get_queue_info
PurposeCurrent build queue: pending builds and wait reasons
Operation TypeRead
Tooljenkins.get_scm_info
PurposeSCM details for a job: repo, branch, last commit
Operation TypeRead

Read operations execute freely; the agent can inspect build logs, job configs, and queue status without asking for approval. Write operations (triggering builds) go through the human approval gate, just like Kubernetes mutations.

Secure Authentication: CSRF and API Tokens

Jenkins authentication via API requires handling two security mechanisms that trip up most automation:

CSRF Protection (crumb). Jenkins generates a CSRF token (called a "crumb") that must be included in every modifying request. Most CI/CD automation scripts either disable CSRF (insecure) or hardcode crumb fetching in a fragile way.

Skyflo's Jenkins MCP server handles CSRF transparently:

  1. Before any write operation, the server fetches a fresh crumb from Jenkins's crumb issuer endpoint.
  2. The crumb is included in the request headers automatically.
  3. If the crumb expires (Jenkins restart, session timeout), the server re-fetches.

The operator never sees or manages crumbs. The authentication flow is:

code
Agent → MCP Server → [Fetch Crumb] → [Include Crumb + API Token] → Jenkins API

API Token Authentication. Skyflo stores Jenkins credentials as Kubernetes Secrets, following the same pattern used for all integration credentials. The MCP server reads the API token from the secret at runtime. Credentials never appear in logs, tool call parameters, or the agent's context window.

yaml
apiVersion: v1
kind: Secret
metadata:
  name: jenkins-credentials
  namespace: skyflo-system
type: Opaque
data:
  url: aHR0cHM6Ly9qZW5raW5zLmludGVybmFsLmV4YW1wbGUuY29t
  username: c2t5ZmxvLWJvdA==
  api-token: MTE3NzRhZDVjZWY4NGM5ZTk5MTBiZWEwMWZiYWUwNGI=

The agent calls jenkins.get_build_log(job_name="deploy-api", build_number=142). The MCP server authenticates to Jenkins using the stored credentials. The agent never sees the credentials; it only sees the build log content.

Natural Language Build Management

With Jenkins MCP tools, the agent can interpret natural language requests about builds:

"What's the status of the latest deploy-api build?"

The agent calls jenkins.get_job_info(job_name="deploy-api") and jenkins.get_build_info(job_name="deploy-api", build_number="lastBuild"):

Build #142 of deploy-api:

- Status: FAILURE

- Duration: 4m 32s

- Triggered by: GitHub push (commit abc123f)

- Parameters: ENVIRONMENT=production, IMAGE_TAG=v2.14.0, DEPLOY_TIMEOUT=300

- Failed stage: "Deploy to Kubernetes" (step 4 of 5)

"Show me the error from build 142."

The agent calls jenkins.get_build_log(job_name="deploy-api", build_number=142) and analyzes the output. Instead of dumping 1,200 lines, it identifies the relevant error:

Build 142 failed at the "Deploy to Kubernetes" stage. The error is on line 847:

```

FATAL: helm upgrade --install api-gateway ./charts/api-gateway \

--namespace production \

--set image.tag=v2.14.0 \

--timeout 300s

Error: UPGRADE FAILED: timed out waiting for the condition

```

The Helm upgrade timed out after 300 seconds. This typically means the new pods failed to reach a Ready state within the timeout.

This is where the multi-tool advantage becomes clear. The agent doesn't just report the Jenkins error; it can immediately investigate the Kubernetes side.

"Why did the Helm upgrade time out?"

The agent now switches to Kubernetes MCP tools:

code
kubernetes.list_pods(namespace="production", label_selector="app=api-gateway")
code
NAME                          READY   STATUS             RESTARTS   AGE
api-gateway-5d8f7c9b4-k2m8n  0/1     ImagePullBackOff   0          6m
api-gateway-5d8f7c9b4-p4q6r  0/1     ImagePullBackOff   0          6m
api-gateway-7b3a1e5d2-x9y1z  1/1     Running            0          2d
api-gateway-7b3a1e5d2-w7v3u  1/1     Running            0          2d

The new pods are in ImagePullBackOff. The agent checks events:

code
kubernetes.get_events(namespace="production", field_selector="involvedObject.name=api-gateway-5d8f7c9b4-k2m8n")
code
Warning  Failed   6m  kubelet  Failed to pull image "registry.internal/api-gateway:v2.14.0":
                               rpc error: code = NotFound desc = failed to pull and unpack image:
                               not found

The image v2.14.0 doesn't exist in the registry. The Jenkins build built and tagged the image as v2.14.0, but the push step failed silently, or the tag was wrong.

Full Walkthrough: Debugging a Failed Deployment Pipeline

Let's trace the complete debugging workflow from a natural language prompt through to resolution.

The Situation: The deploy-api Jenkins job failed. The team gets a Slack notification: "Build #142 failed." Someone asks Skyflo to investigate.

Step 1: Initial Investigation

User: "deploy-api build 142 failed. What happened?"

The agent calls:

  • jenkins.get_build_info(job_name="deploy-api", build_number=142): gets build metadata, parameters, status
  • jenkins.get_build_log(job_name="deploy-api", build_number=142): gets the full console output
  • jenkins.get_scm_info(job_name="deploy-api"): gets the commit that triggered the build

Agent's findings:

Build #142 of deploy-api failed after 4m 32s.

Trigger: GitHub push, commit abc123f on branch main

Parameters: ENVIRONMENT=production, IMAGE_TAG=v2.14.0, DEPLOY_TIMEOUT=300

Pipeline stages:

1. Checkout — SUCCESS (3s)

2. Build Image — SUCCESS (2m 14s)

3. Push Image — SUCCESS (45s)

4. Deploy to Kubernetes — FAILURE (1m 30s, then timeout)

5. Run Smoke Tests — SKIPPED

Error: Helm upgrade timed out. New pods in ImagePullBackOff.

Analysis: The "Push Image" stage reported success, but the Kubernetes pods cannot pull registry.internal/api-gateway:v2.14.0. Possible causes:

1. Image was pushed to a different registry or with a different tag

2. Image push succeeded but registry is not accessible from the cluster

3. Image tag was overwritten or deleted between push and pull

Step 2: Cross-Tool Correlation

The agent investigates the Kubernetes side:

  • kubernetes.list_pods(namespace="production", label_selector="app=api-gateway"): finds ImagePullBackOff pods
  • kubernetes.get_events(namespace="production"): finds "Failed to pull image: not found" events

And goes back to Jenkins to check the push stage more carefully:

  • Analyzes the build log around the "Push Image" stage:
code
[Stage: Push Image]
+ docker push registry.internal/api-gateway:v2.14.0
The push refers to repository [registry.internal/api-gateway]
v2.14.0: digest: sha256:a1b2c3d4... size: 1234

The push log looks clean. The image was pushed successfully. So why can't Kubernetes pull it?

The agent checks the deployment's image pull configuration:

code
kubernetes.get_resource(resource_type="deployment", name="api-gateway", namespace="production")
yaml
spec:
  template:
    spec:
      containers:
        - name: api-gateway
          image: registry.internal/api-gateway:v2.14.0
          imagePullPolicy: Always
      imagePullSecrets:
        - name: registry-credentials

The agent checks the imagePullSecret:

code
kubernetes.get_resource(resource_type="secret", name="registry-credentials", namespace="production")

The secret exists, but the agent notes it was last modified 90 days ago. If the registry password was rotated, the secret might contain expired credentials.

Agent's updated assessment:

Root cause identified: The image registry.internal/api-gateway:v2.14.0 was pushed successfully (confirmed in Jenkins build log). The Kubernetes pods cannot pull it because the registry-credentials imagePullSecret in the production namespace contains expired credentials. The secret was last updated 90 days ago.

Recommended fix: Update the registry-credentials secret with current registry credentials, then restart the rollout.

Step 3: Approval and Execution

The agent presents the fix for approval:

code
Action 1: Update secret/registry-credentials in production
  Key: .dockerconfigjson
  Value: [new credentials from credential store]

Action 2: Restart rollout of deployment/api-gateway in production
  This will trigger new pods that use the updated pull secret.

The operator reviews:

  • The target is correct (registry-credentials, production namespace)
  • The approach is correct (update secret, then restart)
  • The scope is contained (one secret, one deployment restart)

Approved.

The agent executes:

  1. kubernetes.patch_resource(resource_type="secret", name="registry-credentials", namespace="production", patch=...): updates the secret
  2. kubernetes.rollout_restart(resource_type="deployment", name="api-gateway", namespace="production"): triggers a new rollout

Step 4: Verification

The agent verifies:

  • kubernetes.get_rollout_status(name="api-gateway", namespace="production"): rollout complete
  • kubernetes.list_pods(namespace="production", label_selector="app=api-gateway"): all pods running, no ImagePullBackOff
  • kubernetes.get_events(namespace="production"): no new pull errors
code
$ kubectl get pods -n production -l app=api-gateway
NAME                          READY   STATUS    RESTARTS   AGE
api-gateway-8f2c4d6a1-b3e5g  1/1     Running   0          1m
api-gateway-8f2c4d6a1-h7j9k  1/1     Running   0          1m

The agent also suggests a follow-up:

Verification: PASSED. All pods running with image v2.14.0.

Recommendation: Re-trigger the deploy-api job's smoke test stage to validate the deployment end-to-end.

Long-term fix: Rotate the registry-credentials secret as part of the credential rotation pipeline to prevent expiration.

Step 5: Retrigger Smoke Tests

User: "Go ahead and retrigger the deploy-api job with just the smoke test stage."

The agent prepares the tool call:

code
Tool: jenkins.build_job
Parameters:
  job_name: deploy-api
  parameters:
    ENVIRONMENT: production
    IMAGE_TAG: v2.14.0
    SKIP_BUILD: true
    SKIP_PUSH: true
    SKIP_DEPLOY: true
    RUN_SMOKE_TESTS: true

Approval request: "Trigger deploy-api build with smoke tests only. Parameters: ENVIRONMENT=production, IMAGE_TAG=v2.14.0, skip build/push/deploy. Approve?"

Approved. The build triggers. The agent monitors the build progress via jenkins.get_build_info and reports:

Build #143 of deploy-api: SUCCESS (1m 12s)

Smoke tests passed: 47/47

Deployment of v2.14.0 to production is fully verified.

Parameter-Aware Job Management

One of the most error-prone aspects of Jenkins is parameterized builds. Jobs often have 5-10 parameters with defaults, enums, and dependencies. Triggering a build with the wrong parameters can deploy the wrong version to the wrong environment.

Skyflo's Jenkins MCP tools are parameter-aware:

Discovery: When the agent calls jenkins.get_job_info, it receives the full parameter definition: name, type, default value, description, and choices (for choice parameters). This means the agent can:

  • Validate parameter values before triggering a build
  • Suggest defaults based on the job's configuration
  • Warn when a parameter combination seems unusual ("You're setting ENVIRONMENT=production with SKIP_TESTS=true. Are you sure?")

Intelligent defaults: When you say "deploy v2.14.0 to staging," the agent maps your intent to the correct parameters:

code
jenkins.build_job(
  job_name="deploy-api",
  parameters={
    "IMAGE_TAG": "v2.14.0",
    "ENVIRONMENT": "staging",
    "DEPLOY_TIMEOUT": "300",  // default
    "RUN_SMOKE_TESTS": "true" // default
  }
)

You didn't specify timeout or smoke tests. The agent used the job's configured defaults. If you had said "deploy to staging without smoke tests," it would have set RUN_SMOKE_TESTS=false.

Audit trail: Every build triggered via Skyflo is logged with the full parameter set, who approved it, and the timestamp. This is the audit trail that manual Jenkins interactions (clicking "Build with Parameters" in the web UI) typically lack.

Integrating Jenkins with the Full Operational Context

The real power of Jenkins MCP tools isn't Jenkins in isolation; it's Jenkins integrated with the rest of your operational context. When a Jenkins build deploys to Kubernetes, the agent can:

  1. Trigger the build (Jenkins MCP)
  2. Monitor the deployment (Kubernetes MCP: watch pods, check rollout status)
  3. Validate the release (Helm MCP: check release status, compare values)
  4. Check application health (Prometheus MCP: query error rates, latency)
  5. Roll back if needed (Helm MCP: rollback to previous release, with approval)

This cross-tool orchestration (Jenkins + Kubernetes + Helm + Prometheus) is the use case that no single tool provides. It's why platform teams are moving toward AI agents that span the operational stack, not point tools that automate one piece. See the full supported tools list for all available MCP integrations.

Try Skyflo

Bring Jenkins into your AI-powered operational workflow. Natural language builds, intelligent log analysis, and cross-tool correlation, all with human-in-the-loop safety.

bash
helm repo add skyflo https://charts.skyflo.ai
helm install skyflo skyflo/skyflo
Schedule a Demo

See Skyflo in Action

Book a personalized demo with our team. We'll show you how Skyflo can transform your DevOps workflows.