MergeRequest: end-to-end GLQL aggregation integration
Enable MergeRequest analytics queries using GLQL with `mode: analytics` syntax, building on the existing MergeRequest aggregation engine.
The backend aggregation engine needs to be implemented first. This epic tracks the **full implementation** of MergeRequest analytics in GLQL.
**Parent Epic:** &21207 Data Aggregation in GLQL
## Example Query
```yaml
mode: analytics
query: type = MergeRequest and created >= -30d and state = "merged"
dimensions:
- author as "Author"
- targetBranch as "Target Branch"
metrics:
- count as "Total MRs"
- medianTimeToMerge as "Median Time to Merge"
- throughput as "MR Throughput"
sort: throughput desc
limit: 20
```
This query returns merge request analytics grouped by author and target branch, showing throughput and time-to-merge metrics for the last 30 days.
## Goals
1. Implement backend aggregation engine for MergeRequests
2. Add GLQL parser support for `type = MergeRequest` + `mode: analytics`
3. Enable querying MR productivity metrics (throughput, time to merge, approval metrics)
4. Make MergeRequest analytics accessible to Data Analyst agent
5. Document query patterns and examples
## Scope
**✅ In Scope:**
- Implement `Analytics::AggregationEngines::MergeRequests` engine
- Create `mergeRequestAnalytics` GraphQL field
- GLQL parser support for `type = MergeRequest` + `mode: analytics`
- GLQL UI integration for MergeRequest queries
- Documentation: GLQL syntax examples, query patterns
- Data Analyst agent integration (prompts, example questions)
- Feature flag: `glql_merge_request_analytics_aggregation`
**❌ Out of Scope (Future Work):**
- Additional MR metrics beyond core use cases
- Migration of existing MR analytics dashboards
- Performance optimization for large-scale deployments
**✅ Prerequisites:**
- Backend engine (#589619) must be completed first
- GraphQL field must be mounted
## Related Work
- Backend Engine: https://gitlab.com/gitlab-org/gitlab/-/work_items/589619
- Research: https://gitlab.com/gitlab-org/gitlab/-/work_items/588589
- Parent Epic: https://gitlab.com/groups/gitlab-org/-/work_items/21207
- Aggregation Framework Docs: https://docs.gitlab.com/development/database/aggregation_framework/
- Reference Pattern: https://gitlab.com/groups/gitlab-org/-/work_items/21212
## Success Criteria
- [ ] GLQL queries with `mode: analytics` successfully return MergeRequest aggregation data
- [ ] Data Analyst agent can answer questions like "Show me MR throughput by author this month"
- [ ] Documentation published with working examples
- [ ] Pattern consistent with Pipeline and CodeSuggestion implementations
## Implementation Flow
```mermaid
graph TB
subgraph "Per data type process"
subgraph "Backend (Optimize)"
ENGINE[1. Backend Engine<br/>Implement aggregation<br/>Weight: 3]
GRAPHQL[2. GraphQL Field<br/>Mount engine<br/>Weight: 2]
end
subgraph "GLQL Integration (Platform Insights)"
PARSER[3. Parser Support<br/>Add analytics mode<br/>Weight: 3]
subgraph "Parallel Work"
UI[4. UI Integration<br/>Render results<br/>Weight: 3]
DOCS[5. Documentation<br/>Examples & guides<br/>Weight: 2]
AGENT[6. Agent Integration<br/>Prompts & patterns<br/>Weight: 2]
end
end
ENGINE --> GRAPHQL
GRAPHQL -.Schema Handoff.-> PARSER
PARSER --> UI
PARSER --> DOCS
PARSER --> AGENT
end
```
**Implementation flow for this data type:** Sequential backend work by Optimize team, then parallel GLQL integration by Platform Insights team. The dotted "Schema Handoff" line shows where early schema sharing can unblock Platform Insights to start parser work before GraphQL is fully complete.
epic