Segment Developer activity and Project exposure by agent class
What does this MR do and why?
Segment Developer activity and Project exposure by agent class.
The AI Governance dashboard has a segmented control at the top ("Show: All agents | DAP | Connected") that maps to the AiGovernanceAgentClass GraphQL enum (ALL, INTERNAL_DAP, EXTERNAL). It shipped in !251357 (merged), but it only re-queried the two summary KPI tiles (AI agents, AI sessions). The four data cards below ignored it.
The backend for the two ranked-list cards already supported segmentation before this MR. aiGovernanceMetrics(agentClass:) is applied in PostgresqlMetricsService#base_scope via for_agent_class, and the ClickHouse path threads agent_class_filter into the ranking query. topUsers and topProjects both build off that. The frontend just wasn't sending the argument, so Developer activity and Project exposure silently showed all-agent data no matter what the user picked. That's a correctness problem on a governance dashboard: the card contradicted the selected filter.
This MR is frontend only:
- Adds
AGENT_CLASS_ALL/AGENT_CLASS_INTERNAL_DAP/AGENT_CLASS_EXTERNALtoee/app/assets/javascripts/ai/governance/constants.js, since three components now need the enum values, and switchesdashboard_app.vueoff its localDEFAULT_AGENT_CLASSliteral. - Adds
$agentClass: AiGovernanceAgentClasstoget_developer_activity.query.graphqlandget_project_exposure.query.graphql, passed asaiGovernanceMetrics(agentClass: $agentClass). - Adds an
agentClassprop (defaultALL) todeveloper_activity_card.vueandproject_exposure_card.vue, threaded into the Apollo query variables so changing it re-runs the query. - Passes
:agent-class="agentClass"fromdashboard_app.vuedown to both cards.
Out of scope for this MR: the Audit logs card and Agent inventory card are still unsegmented. The audit card needs an agentClass argument on duoWorkflowSessionArtifacts, tracked in !251518 (merged). The inventory card needs the connected-agents data source added in !253516 (merged) (merged) and will get its own frontend MR.
References
- Work item: https://gitlab.com/gitlab-org/gitlab/-/work_items/618950 (Frontend: switch between DAP and ECA)
- Epic: https://gitlab.com/groups/gitlab-org/-/epics/18973
- The control itself: !251357 (merged)
- Audit card segmentation: !251518 (merged)
- Connected agents API: !253516 (merged)
Screenshots or screen recordings
Pending. Will add before/after screenshots of the two cards updating as the "Show" control changes.
| Before | After |
|---|---|
How to set up and validate locally
- Enable the feature flag for a group:
Feature.enable(:ai_governance_dashboard) - Visit the group's GitLab Duo governance settings page and open the dashboard tab.
- Use the "Show" control to switch between All agents, DAP, and Connected.
- Confirm the Developer activity and Project exposure cards re-query and their data changes with the selection, instead of staying static.
- Optionally watch the network tab:
getDeveloperActivityandgetProjectExposurerequests should carry theagentClassvariable matching the current selection.
Tests
ee/spec/frontend/ai/governance/components/dashboard is green, 74 examples. Added per card: defaults to ALL, segments by a given agent class, and re-runs the query when the prop changes. Added to dashboard_app_spec.js: an it.each over both cards asserting the selected class propagates from the control down to the card props. Prettier and ESLint clean.
MR acceptance checklist
Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.