| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
|
Hi @klesh could you please review and approve pull request? |
Sorry, something went wrong.
|
Hi @ewega could you please review and approve pull request. |
Sorry, something went wrong.
# Conflicts: # backend/plugins/gh-copilot/models/migrationscripts/register.go # backend/plugins/gh-copilot/models/models.go # backend/plugins/gh-copilot/models/user_metrics.go # backend/plugins/gh-copilot/tasks/register.go # backend/plugins/gh-copilot/tasks/report_download_helper.go # backend/plugins/gh-copilot/tasks/user_metrics_extractor.go
|
@klesh can you please merge pull request ? |
Sorry, something went wrong.
|
@bujjibabukatta Most tests are failing and the application does not compile when locally deployed. Can you please take a look? |
Sorry, something went wrong.
… migration, register AI-credit-usage tables, fix table count test
|
@ewega Thanks for flagging this. I've pushed changes that fix the failing tests and the compile issue. The QC checks don't seem to have triggered yet on the latest push — could you help re-trigger them (or approve the workflow run) when you get a chance? Happy to address anything else that comes up. |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
Closes #8964
Summary
The gh-copilot plugin pins the correct Copilot metrics API version
(2026-03-10) but is only partially implemented against it: several
response fields are dropped on extract, org-level rows lose their
identity, three endpoints aren't called at all, and a response-body
bug silently zeroes out both the enterprise and user report collectors.
Bugfixes
Double-read bug (2 occurrences). parseRawReportResponse and
parseUserMetricsReportResponse each read res.Body once directly,
then again inside parseReportMetadataResponse. The second read
always came back empty, so meta was always nil and every
enterprise/user report was silently discarded — no error, no rows.
Fixed by reading once in both places.
Org identity. ExtractOrgMetrics hardcoded EnterpriseId: "" and
never set OrganizationId, so org-level rows in the shared daily
metrics table had no identity of their own. Now stamps
OrganizationId from the report (falling back to the connection's
configured org), and passes EnterpriseId through instead of forcing
it blank.
Field gaps
ai_adoption_phase field names (including the 2026-07-07 review-cycle
fields and 2026-06-26 total_pull_requests_merged) were checked
against GitHub's changelog posts.
Missing endpoints
Implements enterprise-28-day/latest, organization-28-day/latest,
users-28-day/latest. These are single "latest" snapshot calls (no
day param, unlike the -1-day reports) whose payload wraps entries in
a day_totals[] array. Reuses the existing enterpriseDayTotal/
userDailyReport shapes for the entries; writes to new, separate
tables so this cadence can't silently overwrite -1-day rows for the
same (connection, scope, day). Per-IDE/feature/language breakdowns
are out of scope for 28-day data in this pass — the -1-day breakdowns
already cover those dimensions.
Migrations
adoption phase table
Migration struct field names were cross-checked against the real
model structs field-by-field to make sure AutoMigrateTables targets
the right columns.
Testing
non-empty daily metrics tables (regression test for the
double-read bug)