Metrics updates#26348
Conversation
This PR addresses two critical issues identified in the repository's metrics collection process: 1. **Short Historical Window**: The `metrics/index.ts` script was hardcoded to keep only the last 100 lines of `metrics-timeseries.csv`. Given that each run generates approximately 73 metrics, this effectively purged almost all historical data on every run, breaking 7-day and 30-day delta calculations. 2. **Missing Backlog Age Visibility**: While we track the number of open issues, we lacked a metric to measure the average age of the backlog, which is crucial for identifying stagnation. ## Changes - **Metrics Retention**: Increased the rolling window in `tools/gemini-cli-bot/metrics/index.ts` from 100 to 5000 rows. - **New Metric**: Added `tools/gemini-cli-bot/metrics/scripts/backlog_age.ts` to calculate the average age of the oldest 100 open issues. - **Fix**: Ensured the new script is lint-clean, avoiding the "unused variable" error that caused previous attempts to fail. ## Impact - Accurate delta calculations for all metrics. - Better visibility into the health of the issue backlog, enabling proactive triage of aging issues.
|
Hi @gemini-cli[bot], thank you so much for your contribution to Gemini CLI! We really appreciate the time and effort you've put into this. We're making some updates to our contribution process to improve how we track and review changes. Please take a moment to review our recent discussion post: Improving Our Contribution Process & Introducing New Guidelines. Key Update: Starting January 26, 2026, the Gemini CLI project will require all pull requests to be associated with an existing issue. Any pull requests not linked to an issue by that date will be automatically closed. Thank you for your understanding and for being a part of our community! |
|
Size Change: -4 B (0%) Total Size: 33.9 MB
ℹ️ View Unchanged
|
|
@gemini-cli please explain this change to me:
|
|
The changes in this PR address two key gaps in our repository health monitoring: 1. What does it accomplish?
2. How are you going to use this information?This data is consumed by the Brain (Reasoning Layer), specifically in the
3. Relation to the longer-term planMy goal is to transition the repository from reactive maintenance to proactive self-optimization.
Note: While you tagged |
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request improves the reliability and depth of the project's metrics collection. By expanding the historical data retention window, it ensures that long-term trend analysis remains accurate. Additionally, the inclusion of a new backlog age metric enables more proactive management of open issues. Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. Footnotes
|
There was a problem hiding this comment.
Code Review
This pull request increases the metrics history limit to 5000 lines and adds a script to calculate the average age of open GitHub issues. Feedback suggests using execFileSync instead of execSync to ensure the script works correctly across different platforms, particularly when handling multi-line GraphQL queries.
| */ | ||
|
|
||
| import { GITHUB_OWNER, GITHUB_REPO } from '../types.js'; | ||
| import { execSync } from 'node:child_process'; |
There was a problem hiding this comment.
Prefer using execFileSync over execSync to ensure better robustness and cross-platform compatibility, especially when dealing with multi-line arguments or potential shell-specific behavior. Synchronous operations are acceptable in this script context per repository guidelines.
| import { execSync } from 'node:child_process'; | |
| import { execFileSync } from 'node:child_process'; |
References
- For test environment setup and scripts, it is acceptable to use synchronous operations (e.g., fs.*Sync, execSync) within an async function for simplicity and readability.
| const output = execSync( | ||
| `gh api graphql -F owner=${GITHUB_OWNER} -F repo=${GITHUB_REPO} -f query='${query}'`, | ||
| { encoding: 'utf-8', stdio: ['ignore', 'pipe', 'ignore'] }, | ||
| ).trim(); |
There was a problem hiding this comment.
Using execSync with a string and shell interpolation is fragile. Specifically, the multi-line query string will cause this command to fail on Windows environments using cmd.exe. Switching to execFileSync with an array of arguments avoids shell parsing issues and ensures the script works correctly across different platforms. Synchronous execution is acceptable in this script context.
const output = execFileSync(
'gh',
[
'api',
'graphql',
'-F',
'owner=' + GITHUB_OWNER,
'-F',
'repo=' + GITHUB_REPO,
'-f',
'query=' + query,
],
{ encoding: 'utf-8', stdio: ['ignore', 'pipe', 'ignore'] },
).trim();References
- For test environment setup and scripts, it is acceptable to use synchronous operations (e.g., fs.*Sync, execSync) within an async function for simplicity and readability.
|
Co-authored-by: gemini-cli[bot] <gemini-cli[bot]@users.noreply.github.com>
Co-authored-by: gemini-cli[bot] <gemini-cli[bot]@users.noreply.github.com>
Description
This PR addresses two critical issues identified in the repository's metrics collection process:
metrics/index.tsscript was hardcoded to keep only the last 100 lines ofmetrics-timeseries.csv. Given that each run generates approximately 73 metrics, this effectively purged almost all historical data on every run, breaking 7-day and 30-day delta calculations.Changes
tools/gemini-cli-bot/metrics/index.tsfrom 100 to 5000 rows.tools/gemini-cli-bot/metrics/scripts/backlog_age.tsto calculate the average age of the oldest 100 open issues.Impact