-
Notifications
You must be signed in to change notification settings - Fork 594
feat(general): add stats to maintenance run #4890
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
feat(general): add stats to maintenance run #4890
Conversation
7dd92ba to
f6f6841
Compare
julio-lopez
left a comment
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.
Please rename fields to Extra and Data.
Add marshaling unit tests
|
As soon as feedback is addressed, CI can run and this PR can be merged afterwards |
7f0ba55 to
6cff24e
Compare
6cff24e to
b83d95d
Compare
|
@julio-lopez However, for "Add marshaling unit tests", I cannot add UT for the current PR.
Which way do you prefer? And can you give some advice? |
| type Summarizer interface { | ||
| Summary() string | ||
| } | ||
|
|
||
| // Kind defines the methods for detecting kind of a maintenance statistics. | ||
| type Kind interface { |
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.
No change requested, only a comment: it seems that these did not need to be separated, what's the rationale for separating them?
Anyway, we can merge as is and roll the ball forward.
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.
it seems that these did not need to be separated, what's the rationale for separating them?
I just feel that they don't need to be from the same implementation --- the task functions who generate the statistics structs don't need to know what Summary mean, this Summarizer should not appear in these functions' signature (return value).
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## master #4890 +/- ##
==========================================
+ Coverage 75.86% 76.73% +0.86%
==========================================
Files 470 536 +66
Lines 37301 40981 +3680
==========================================
+ Hits 28299 31446 +3147
- Misses 7071 7489 +418
- Partials 1931 2046 +115 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
The suggestion is to have simple tests that ensure the struct marshaling/unmarshaling "round-trips", that is:
These tests are simple, they DO NOT require a complex setup such to run maintenance, forcing it to create a schedule, etc. |
| return succeed | ||
| } | ||
|
|
||
| extraStr := "" |
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.
| extraStr := "" | |
| extraStr := "" | |
| } | ||
|
|
||
| // BuildFromExtra builds maintenance statistics from an Extra and returns a Summarizer. | ||
| func BuildFromExtra(extra Extra) (Summarizer, error) { |
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.
| func BuildFromExtra(extra Extra) (Summarizer, error) { | |
| func BuildFromExtra(_ Extra) (Summarizer, error) { |
| func BuildExtra(stats Kind) (Extra, error) { | ||
| bytes, err := json.Marshal(stats) | ||
| if err != nil { | ||
| return Extra{}, errors.Wrapf(err, "error marshalling stats %v", stats) |
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.
| return Extra{}, errors.Wrapf(err, "error marshalling stats %v", stats) | |
| return Extra{}, errors.Wrapf(err, "error marshaling stats %v", stats) |
|
Merging as is, I'll take care of the linter issues in a separate PR. |
|
For the PRs to follow, please run the linter and other CI jobs in your computer, or in your repository so you catch any test and linter errors early. This reduces the number of back-and-forth and overall speeds up the PR review process and thus, merging the changes. |
Sure, so it is more like a UT. Will add it in the next PR. |
Maintenance is critical for healthy of the repository.
On the other hand, Maintenance is complex, because it runs multiple sub tasks each may generate different results according to the maintenance policy. The results may include deleting/combining/adding data/metadata to the repository.
It is worthy to add more observability for these tasks for below reasons:
There will be a serial of PRs to add observability info for each sub task.
The current PR adds the interfaces, structures and workflows to save, retrieve and display the statistics info for maintenance tasks.