-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
monitoring PR handling failures. #42
Conversation
We both explicit failures with pr_handle_failures_total And cases where telefonistka commit status check is left in "pending" state (because Telefonistka exploded while handling that event )
This way we can also monitor the successes, so we can get a ratio or just the activity rate of the repo and such
Express const timeframes in time (not int)
improve error handeling Add context timeout
time.After(60time.Second) |
Sample from Lab:
|
if err != nil { | ||
log.Errorf("error getting PRs for %s/%s: %v", ghOwner, repo.GetName(), err) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not checking the error first, and then calling the prom.InstrumentGhCall(resp)
?
Another question if the output for prom.InstrumentGhCall(resp)
is not important why do bother to assign it something?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The InstrumentGhCall
function returns labels just for testing.
During runtime these labels are just used internally in the function.
I chose to instrument before error handling to ensure we still instrument even if we change the error handling to break out of that code path in the future, be I can change the order if you feel it makes it less readable
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I chose to instrument before error handling to ensure we still instrument even if we change the error handling to break out of that code path in the future, be I can change the order if you feel it makes it less readable
I would add that as a comment
Co-authored-by: Yazdan Mohammadi <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This PR adds a few metrics to Telefonistka process
Description
Note: Just a metric to track activity in repo.
Note: Could be used to check if we need to enforce merging/closing stale promotion PRs
Note: those represent cases the Telefonsitka totaly failed, not even marking the checks as fialed
We can use this track failure telefonistika is aware of
Type of Change
Checklist