ci(telemetry): put the monthly refresh back on a schedule - #645
ci(telemetry): put the monthly refresh back on a schedule#645Timur Tukaev (tym83) wants to merge 2 commits into
Conversation
The cron was paused because /api/overview undercounted about threefold: it counted with an instant PromQL query and saw only the clusters that had reported in the last few minutes, roughly 50 of them. The published numbers were pulled from the Grafana dashboard by hand instead. The server has counted over the period window since telemetry-server 43617cc (2026-06-30) — every selector wrapped in max_over_time over the month. Checked before re-enabling: the API returns 1162 / 3697 / 2180 for June today, matching the hand-pulled figures published last month to the digit. The reason to keep it manual is gone. It runs on the 3rd and asks for the month before, which is the month the server has a final snapshot of. That month is derived from the day before the 1st of the current one rather than from "last month" — the latter keeps the day number and silently skips a month when run on a 29th or later. Signed-off-by: tym83 <6355522@gmail.com>
✅ Deploy Preview for cozystack ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughThe telemetry workflow now runs on the third day of each month and fetches data for the previous closed month. It passes the resolved year and month to the fetch step and uses them in the commit message. The script documentation references the monthly workflow. ChangesMonthly telemetry automation
Estimated code review effort: 2 (Simple) | ~10 minutes Sequence Diagram(s)sequenceDiagram
participant GitHubActions
participant PeriodResolver
participant TelemetryFetch
participant GitCommit
GitHubActions->>PeriodResolver: Start on the third day of the month
PeriodResolver->>TelemetryFetch: Pass TELEMETRY_YEAR and TELEMETRY_MONTH
TelemetryFetch->>GitCommit: Commit telemetry data with the resolved year-month
Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Aleksei Sviridkin (lexfrei)
left a comment
Aleksei Sviridkin (lexfrei)
left a comment
There was a problem hiding this comment.
NOT LGTM — the change itself checks out end to end, but it leaves one line of documentation in the touched area describing the pre-PR reality.
Business context: Re-enables the monthly telemetry cron paused in April 2026 over the ~3x /api/overview undercount; the server-side fix (cozystack-telemetry-server 43617cc, 2026-06-30) landed, and the API now returns exactly the June figures that were published by hand (1162 / 3697 / 2180 — verified against the live API during review).
Blockers
B1: hack/fetch_telemetry.py docstring still calls the workflow "manual"
File: hack/fetch_telemetry.py:19
Issue: "Used by the manual telemetry workflow and by developers…" was accurate while the workflow was workflow_dispatch-only; this PR puts it back on a monthly schedule, so "manual" no longer describes reality.
Evidence: The diff adds schedule: - cron: '0 5 3 * *' to .github/workflows/fetch-telemetry.yml; the docstring wording dates from the pause commit and described that state.
Impact: The next reader assumes telemetry updates still require a human trigger.
Fix: One word — "Used by the monthly telemetry workflow and by developers who need to refresh or backfill the seed file locally."
Non-blocking follow-ups
workflow_dispatchcould take optionalyear/monthinputs for real backfill from the UI — the script already honoursTELEMETRY_YEAR/TELEMETRY_MONTH. Worth adding only if backfills turn out to happen more than about once a year.
Checked and clean: the script reads TELEMETRY_YEAR/TELEMETRY_MONTH (hack/fetch_telemetry.py:188-189) and int("07") is fine in Python 3; the date arithmetic survives the year boundary (2026-01 → 2025-12) and short February; the manual-dispatch behavior change (previous closed month instead of the current open one) is declared in the workflow comments and loses no capability; no injection risk in the ${{ }} interpolation — values come from date, not external input.
The module docstring still described the workflow as manual after the monthly cron was restored. Signed-off-by: tym83 <6355522@gmail.com>
|
Aleksei Sviridkin (@lexfrei) addressed — the module docstring in |
2 participants
Summary
Re-enables the monthly telemetry cron. Split out from #644, which publishes the July data — this one is a process change and deserves its own decision.
Why it was paused
/api/overviewundercounted by roughly threefold. It counted with an instant PromQL query, so it saw only the clusters that had reported in the last few minutes — about 50 — rather than those active over the period. The published numbers were pulled from the Grafana telemetry-overview dashboard by hand instead, and the workflow was reduced toworkflow_dispatch.Why it can come back
The server has counted over the period window since cozystack-telemetry-server 43617cc (2026-06-30): every selector is wrapped in
max_over_time(...[window])covering the month.Checked before re-enabling — the API returns 1162 / 3697 / 2180 for June today, which matches the figures published by hand last month exactly. The discrepancy that justified the manual path is gone.
Timing
Runs on the 3rd and publishes the month before, which is the month the server has a final snapshot of.
The previous month is derived from the day before the 1st of the current one, not from
date -d 'last month': that phrasing keeps the day number, so a run on the 29th, 30th or 31st resolves into the wrong month and silently skips one. Verified for 2026-08-03 → 2026-07, 2026-03-31 → 2026-02, 2026-01-01 → 2025-12.It stays a separate workflow rather than joining the monthly OSS Health job: those datasets come from public APIs, this one from our own telemetry server, and a failure there should not hold back the rest.
Summary by CodeRabbit
New Features
Documentation