Update README.md

[avdongre]

No description provided.

[avdongre]

f you mean how to read Jenkins CI/CD console output (consoleText) programmatically, Jenkins exposes the build log through its REST-style endpoints.

1. Get the console log

For a job:

https://jenkins.example.com/job/my-job/123/consoleText

Where:

my-job = Jenkins job
123 = build number
consoleText = plain-text console output

You can also use:

curl -u "$JENKINS_USER:$JENKINS_API_TOKEN"
"https://jenkins.example.com/job/my-job/123/consoleText"

For a Pipeline, the same endpoint works.

2. What the output looks like

You might get:

Started by user john
[Pipeline] Start of Pipeline
[Pipeline] stage
[Pipeline] { (Build)
[Pipeline] sh

• npm install
  ...
  [Pipeline] sh
• npm test
  Tests: 42 passed, 0 failed
  [Pipeline] }
  [Pipeline] stage
  [Pipeline] { (Deploy)
  ...
  Finished: SUCCESS

The important thing is that consoleText is just text. Jenkins doesn't return a structured JSON representation of each log line.

3. Detect whether the build succeeded

A simple approach is to look for:

Finished: SUCCESS

or:

Finished: FAILURE
Finished: ABORTED
Finished: UNSTABLE

But for reliable automation, don't infer build status from the log. Get the build JSON:

https://jenkins.example.com/job/my-job/123/api/json

For example:

curl -u "$JENKINS_USER:$JENKINS_API_TOKEN"
"https://jenkins.example.com/job/my-job/123/api/json"

Then inspect:

{
"number": 123,
"result": "SUCCESS",
"building": false
}

result is the authoritative build result.

4. If you're parsing logs in an application

A common pattern is:

GET /job/{job}/{build}/consoleText
↓
read text line-by-line
↓
identify stages / commands / errors
↓
extract relevant information
↓
GET /job/{job}/{build}/api/json
↓
use result for final status

For example, if you're building an AI/log parser, you could classify lines into:

Pipeline stages
Shell commands
Errors
Warnings
Test results
Deployment output
Final build status

One important distinction: Jenkins also has progressiveText, which is useful when the build is still running, because you can incrementally fetch newly generated log output rather than repeatedly downloading the entire consoleText.

If you tell me whether you're trying to read consoleText from Java, Python, Node.js, a Jenkins plugin, or an API, I can show the exact implementation.

Yes — for your use case, I would use structured JSON to identify the failed stage, then fetch only the relevant log for that stage and send that to the LLM.

Recommended flow
Jenkins Pipeline
│
▼
Get build/stage metadata (JSON)
│
▼
Identify FAILED stage
│
▼
Fetch logs for that stage/node
│
▼
Extract error context
│
▼
Send relevant logs + metadata to LLM
│
▼
LLM: root cause + explanation + suggested fix

1. Identify the failed stage

If you use the Jenkins Pipeline REST API:

/job/my-pipeline/123/wfapi/describe

You can get stage information such as:

{
"status": "FAILURE",
"stages": [
{
"name": "Build",
"status": "SUCCESS"
},
{
"name": "Test",
"status": "FAILURE"
},
{
"name": "Deploy",
"status": "NOT_EXECUTED"
}
]
}

From this, you immediately know:

Failed stage: Test
2. Get the failed stage's logs

The important limitation is that Jenkins often stores the console output as one overall build log. So your next step is to retrieve the log associated with the failed Pipeline node/stage.

Depending on your Jenkins Pipeline REST API setup, you can retrieve node details/logs, for example via endpoints similar to:

/job/my-pipeline/123/execution/node/{nodeId}/wfapi/describe

and then retrieve the relevant node log.

The exact API availability depends on your installed Jenkins plugins and Pipeline API implementation.

3. Best architecture for your LLM

I recommend sending something like this to your LLM:

{
"pipeline": "payment-service-ci",
"build_number": 123,
"build_status": "FAILURE",
"failed_stage": {
"name": "Test",
"status": "FAILURE"
},
"logs": "Running tests...\nERROR: Connection refused to postgres\n..."
}

Then prompt the LLM:

Analyze this Jenkins CI/CD failure.

Identify:

1. The root cause
2. The specific error causing the failure
3. Whether this is an infrastructure, code, test, dependency, or configuration issue
4. Evidence from the logs
5. Recommended fix

Do not guess. If the logs are insufficient, say what additional information is needed.
My recommendation

Don't send the entire Jenkins consoleText to the LLM unless the logs are small.

Instead:

Use JSON/Pipeline metadata to find the failed stage.
Get the logs for that stage.
Optionally extract a window around ERROR, Exception, FAILED, exit code, etc.
Include perhaps the last 100–300 relevant lines as context.
Send that focused context to the LLM.

A robust architecture would be:

Jenkins
│
├── /api/json
│ └── Build status
│
├── /wfapi/describe
│ └── Find failed stage
│
└── Stage/build logs
│
▼
Log processor
│
├── Detect ERROR / Exception
├── Find stack traces
├── Find failed command
└── Keep surrounding context
│
▼
LLM
│
▼
Root cause + evidence + recommended fix

So yes: use JSON for "which stage failed?" and logs for "why did it fail?". That combination is much better than giving the entire raw consoleText to an LLM.

can you write simple python script for this

Sure. Assuming you have a Jenkins Pipeline and want a simple script that:

Gets build metadata.
Finds the failed stage.
Gets the build console log.
Extracts the section corresponding to that stage.
Prints it so you can later send it to an LLM.

One caveat: Jenkins' standard consoleText doesn't reliably contain stage boundaries in a machine-readable way. For a simple first version, we can use the Pipeline stage markers in the console output.

import requests
import re

JENKINS_URL = "https://jenkins.example.com"
JOB_NAME = "my-pipeline"
BUILD_NUMBER = 123

USERNAME = "your-username"
API_TOKEN = "your-api-token"

session = requests.Session()
session.auth = (USERNAME, API_TOKEN)

def get_build_info():
url = f"{JENKINS_URL}/job/{JOB_NAME}/{BUILD_NUMBER}/api/json"
response = session.get(url)
response.raise_for_status()
return response.json()

def get_pipeline_info():
url = f"{JENKINS_URL}/job/{JOB_NAME}/{BUILD_NUMBER}/wfapi/describe"
response = session.get(url)
response.raise_for_status()
return response.json()

def get_console_log():
url = f"{JENKINS_URL}/job/{JOB_NAME}/{BUILD_NUMBER}/consoleText"
response = session.get(url)
response.raise_for_status()
return response.text

def find_failed_stage(pipeline_info):
for stage in pipeline_info.get("stages", []):
if stage.get("status") == "FAILED":
return stage["name"]

return None

def extract_stage_logs(console_text, stage_name):
"""
Simple extraction based on Jenkins Pipeline stage markers.

Example:
    [Pipeline] { (Test)
    ...
    [Pipeline] }
"""

pattern = (
    r"\[Pipeline\] \{ \("
    + re.escape(stage_name)
    + r"\)\n"
    r"(.*?)"
    r"\[Pipeline\] \}"
)

match = re.search(pattern, console_text, re.DOTALL)

if match:
    return match.group(1)

return None

def main():

print("Getting build information...")
build_info = get_build_info()

print("Build status:", build_info.get("result"))

print("Getting Pipeline information...")
pipeline_info = get_pipeline_info()

failed_stage = find_failed_stage(pipeline_info)

if not failed_stage:
    print("No failed stage found.")
    return

print(f"Failed stage: {failed_stage}")

print("Getting console log...")
console_text = get_console_log()

stage_logs = extract_stage_logs(
    console_text,
    failed_stage
)

if stage_logs:
    print("\n===== FAILED STAGE LOGS =====\n")
    print(stage_logs)
else:
    print("Could not isolate stage logs.")
    print("Falling back to full console log.")

    print(console_text)

if name == "main":
main()
The result

If Jenkins says:

Build: FAILURE

Stages:
Checkout SUCCESS
Build SUCCESS
Test FAILED
Deploy NOT_EXECUTED

the script produces something like:

Failed stage: Test

===== FAILED STAGE LOGS =====

• pytest
  ============================= test session starts =============================

FAILED tests/test_payment.py

E AssertionError: Expected 200 but got 500

=========================== short test summary info ===========================
FAILED tests/test_payment.py

Process exited with code 1

That's the sort of payload I'd then give to the LLM.

One improvement I'd strongly recommend

For a real implementation, don't parse stage logs from consoleText with regex. Jenkins Pipeline stages can contain nested steps, parallel stages, retries, post blocks, etc., so the simple regex will eventually break.

A better implementation is:

Jenkins /wfapi/describe
↓
find failed stage
↓
get stage/node ID
↓
get that node's log
↓
LLM

That gives you a much cleaner architecture:

{
"stage": "Test",
"status": "FAILED",
"log": "AssertionError: Expected 200 but got 500..."
}

If you tell me which Jenkins version/plugins you're using, I can give you the Python version that uses the actual Pipeline node/stage API to fetch only the failed stage's logs, rather than parsing consoleText.

yes nested stages is problem

Exactly. In that case, don't try to determine the failed stage by parsing consoleText. Let Jenkins tell you the stage structure through the Pipeline API, then fetch the log for the corresponding Pipeline node.

A good approach is:

/api/json
│
└── build status
│
/wfapi/describe
│
└── stages + status
│
└── FAILED stage
│
└── node ID
│
▼
node log
│
▼
LLM

For example, a nested Pipeline:

Build
├── Compile SUCCESS
└── Tests FAILURE
├── Unit SUCCESS
└── Integration FAILURE

You want the script to identify:

Failed stage: Integration

rather than trying to regex the console output.

One thing to be aware of: wfapi gives you Pipeline/stage structure, but fetching the exact node log is dependent on the Jenkins Pipeline/Blue Ocean-related plugins and their exposed endpoints. So I wouldn't want to give you a Python script based on an endpoint your Jenkins instance doesn't actually expose.

If you run this against your Jenkins:

curl -u "$JENKINS_USER:$JENKINS_API_TOKEN"
"https://YOUR_JENKINS/job/YOUR_JOB/123/wfapi/describe"

and paste the JSON response here (you can remove URLs, usernames, job names, etc.), I can write the exact Python script to:

recursively handle nested stages
find the deepest failed stage
retrieve its logs
include parent-stage context
produce an LLM-ready JSON payload
avoid sending the entire consoleText to the LLM.