-
Notifications
You must be signed in to change notification settings - Fork 0
Enhance build log tool with timeline and step information #1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
- 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
mkonjikovac
left a comment
There was a problem hiding this 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) |
There was a problem hiding this comment.
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) |
There was a problem hiding this comment.
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) |
There was a problem hiding this comment.
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.
Summary
Enhanced the
get_build_logtool 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
getBuildTimeline()🔍 Step-Level Analysis
Each step now includes detailed metadata:
📈 Build Summary Statistics
Automatic calculation of:
🛠 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
🧪 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.