[all-commits] [llvm/llvm-project] 44f4e4: [CI] Extend metrics container to log BuildKite met...
Nathan Gauër via All-commits
all-commits at lists.llvm.org
Fri Mar 14 03:45:01 PDT 2025
Branch: refs/heads/main
Home: https://github.com/llvm/llvm-project
Commit: 44f4e43b4fbbcc877436be6ae894d594c210fa59
https://github.com/llvm/llvm-project/commit/44f4e43b4fbbcc877436be6ae894d594c210fa59
Author: Nathan Gauër <brioche at google.com>
Date: 2025-03-14 (Fri, 14 Mar 2025)
Changed paths:
M .ci/metrics/metrics.py
Log Message:
-----------
[CI] Extend metrics container to log BuildKite metrics (#130996)
The current container focuses on Github metrics. Before deprecating
BuildKite, we want to make sure the new infra quality is better, or at
least the same.
Being able to compare buildkite metrics with github metrics on grafana
will allow us to easily present the comparison.
BuildKite API allows filtering, but doesn't allow changing the result
ordering. Meaning we are left with builds ordered by IDs. This means a
completed job can appear before a running job in the list. 2 solutions
from there:
- keep the cursor on the oldest running workflow
- keep a list of running workflows to compare.
Because there is no guarantees in workflow ordering, waiting for the
oldest build to complete before reporting any newer build could mean
delaying the more recent build completion reporting by a few hours. And
because grafana cannot ingest metrics older than 2 hours, this is not an
option.
Thus we leave with the second solution: remember what jobs were running
during the last iteration, and record them as soon as they are
completed. Buildkite has at most ~100 pending jobs, so keeping all those
IDs should be OK.
To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications
More information about the All-commits
mailing list