Skip to content

Conversation

@tarunramsinghani
Copy link
Owner

@tarunramsinghani tarunramsinghani commented Nov 5, 2025

Summary

Enhanced the get_build_log tool in the Azure DevOps MCP server to provide comprehensive build analysis by integrating timeline data and step-level information alongside build logs.

What's New

This enhancement transforms the basic log retrieval into a powerful build analysis tool by adding:

📊 Timeline Integration

  • Retrieves build timeline data alongside logs using getBuildTimeline()
  • Maps log entries to their corresponding pipeline steps/tasks
  • Provides step hierarchy and execution order information

🔍 Step-Level Analysis

Each step now includes detailed metadata:

  • Step Information: Name, type (Task/Job/Stage), execution state, and result
  • Timing Data: Start time, finish time, and duration tracking
  • Hierarchy: Parent-child relationships between steps
  • Log Correlation: Direct mapping between steps and their log outputs

📈 Build Summary Statistics

Automatic calculation of:

  • Total logs and steps count
  • Passed/Failed/Skipped step breakdown
  • Currently in-progress steps
  • Overall build health metrics

🛠 Enhanced Data Structure

{
  "logs": [...],           // Original logs with step metadata
  "steps": [...],          // Structured step information
  "buildId": "...",        // Build identifier
  "summary": {             // Statistical overview
    "totalLogs": 15,
    "totalSteps": 12,
    "passedSteps": 10,
    "failedSteps": 1,
    "skippedSteps": 1,
    "inProgressSteps": 0
  }
}

Benefits

🚀 Improved Build Failure Analysis: Quickly identify which specific steps failed
⏱️ Performance Insights: Understand step execution timing and bottlenecks
🔗 Better Context: Log entries now have associated step metadata
📊 At-a-Glance Status: Summary statistics provide immediate build health overview
🎯 Targeted Debugging: Direct correlation between failures and their logs

Use Cases

CI/CD Pipeline Debugging: Rapidly identify failing steps and their causes
Performance Analysis: Track step execution times and optimize workflows
Build Quality Monitoring: Monitor pass/fail rates across pipeline steps
Automated Analysis: Enable AI assistants to provide more accurate build failure diagnostics

Technical Implementation

Parallel API calls to getBuildLogs() and getBuildTimeline() for efficiency
Intelligent mapping between timeline records and log entries
Backward-compatible response structure (existing log format preserved)
Enhanced error context for better troubleshooting

GitHub issue number

microsoft#670

Associated Risks

Low Risk : Additional rest call for timeline but shouold not be an issue.

PR Checklist

  • I have read the contribution guidelines
  • I have read the code of conduct guidelines
  • Title of the pull request is clear and informative.
  • 👌 Code hygiene
  • 🔭 Telemetry added, updated, or N/A
  • 📄 Documentation added, updated, or N/A
  • 🛡️ Automated tests added, or N/A

🧪 How did you test it?

Before the change the analyze build failures with build prompt will not know which step failed and hence will look at logs for all steps or give up and show generic error.

With this the same prompt immedietly identifies the fialed step and only look at logs for that step instead of multiple steps.

azure-pipelines-bot added 2 commits November 5, 2025 15:49
- Add timeline data retrieval to get step details
- Include step information (name, type, state, result, timing)
- Provide enhanced logs with associated step metadata
- Add summary statistics for build steps (passed, failed, skipped)
- Support better build failure analysis with structured step data
- Revert mcp.json to use published package command
- Keep local development configuration in mcp.local.json for development use
- Server/production version should use mcp-server-azuredevops command
@tarunramsinghani tarunramsinghani changed the title Feature/enhanced build log tools Enhance build log tool with timeline and step information Nov 5, 2025
Copy link

@mkonjikovac mkonjikovac left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As per internal discussion with pipelines platform team and our PM, we do not want to include timeline calls into pipeline tools of ADO MCP server at this time.

// Get both logs and timeline information
const [logs, timeline] = await Promise.all([
buildApi.getBuildLogs(project, buildId),
buildApi.getBuildTimeline(project, buildId)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

GetBuildTimeline accepts additional parameters, such as timeline id. Unless provided, it's going to take timelineId associated with the plan here. Timeline is associated with stage runs, this means that every time a stage is retried, a new timeline gets created with id 1, and all the others get their id incremented by 1.
With this approach, we will only be able to get the information of the latest stage runs of the build.

// Get both logs and timeline information
const [logs, timeline] = await Promise.all([
buildApi.getBuildLogs(project, buildId),
buildApi.getBuildTimeline(project, buildId)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Timeline manipulation can be a very demanding operation depending on the size of the pipeline run, which is why we have not included it so far in MCP for pipelines. If this change is absolutely necessary, we should at least cover it via an optional parameter of the tool, e.g. includeTimelineInformation and only in that case call this endpoint.

// Get both logs and timeline information
const [logs, timeline] = await Promise.all([
buildApi.getBuildLogs(project, buildId),
buildApi.getBuildTimeline(project, buildId)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This call will also get all the timeline attempts associated with the timeline. While stage retries are tracked through a new timelines, jobs/phases and tasks retries are tied to the same timeline.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants