-
Notifications
You must be signed in to change notification settings - Fork 32
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
Create an initial stable-rc report email in KCIDB #532
Comments
Hello @crazoes Here is the sample report generated for
The format I have used is from an existing subscription. |
Subject is incorrect - it says the report is for 6.6 kernel but the revision is In the Revision, Build and Tests section - remove though, we can have status section under tests but it should be placed under the |
Hello, Below is the updated report with the modifications as per review discussion:
Here are the addressed review modifications:
Note: I am working on describing failure/error info. We'll discuss Please let me know your thoughts @crazoes. Please note that I have generated report on dummy data so please do not verify/validate 😅 |
|
I think Greg suggested @crazoes to use |
Revised report with build errors:
|
Hi @JenySadadia This report looks much better than previous one. Some more changes which I think we need to make :- Subject is still incorrect, not sure why we are getting the branch name as 6.6 if we are looking at results of 5.16. So we need to fix that before everything else. I think we can also make the subject better. I'm thinking of something like this :- In the overview section, let's also mention the number of build failures and the number of test failures otherwise it gives a little wrong impression of everything failing. In my opinion, we should remove I'm expecting revision to look like this :-
Build section looks really good to me but some more changes that I'd like to see are :-
FYI, there isn't any architecture named Test section is really confusing and it's hard to read it. Let's remove the differentiation of the results from different CI systems. So we shouldn't keep the Tested-by tag in the Test section as well. All the results should be bundled together, no matter from which CI systems it comes from. @JenySadadia for stable-rc we just want to send the boot test results which is
Again, let's remove the summary from it as it doesn't really provide any info At the end of everything, we want to have the following :-
|
yes, it is exactly what @crazoes said about the |
Hello @crazoes Thanks a lot for all the suggestions.
As I stated earlier, the report I generated was on dummy data that's why it was showing incorrect data. I fixed it to have correct output.
Okay. Addressed this.
Makes sense. Updated to have number of passed and failed builds/tests. Also, dropped summary sections for
Oh, sorry for the confusion. I fixed the
Why are we only interested in boot tests? Bdw I have updated the section to have
KCIDB generates an aggregate report from different CI systems' results. I thought it's worth mentioning which CI system reported which failure. Hence, I kept Here is the updated report:
|
On Build failures, may we need a black line between each failure? |
We can use
Yes, I'll add it. |
Oh, yes, I remember, I kept a blank line after a group of CI results. For example,
|
A side note: we need to credit origins when we show and send results, so let's not drop them, but work on improving representation instead. We should not take credit over the resources supplied by other CI systems, but highlight them instead. Jeny, as you work on those changes, could you create separate templates for stable-rc instead of changing the stock ones? And use and expand the template macro libraries, as necessary? This way we could get this merged sooner, and then we can work on integrating what works in the main reports. |
And one more thing: we should avoid putting too much information into the (plain text or even HTML) emails. It quickly becomes unusable as the only controls you have to review the data are scrolling back and forth and string search. I think the emails should act as an alert system, first of all, presenting the most important data succinctly, and directing people towards dashboards, which should have better tools for exploring and representing the information. It should usually also have more data by the time the email is viewed, as we don't really send them when we're "done", because we're potentially never done testing. As a perspective, KernelCI legacy reports were already unreadable due to the amount of data in them. Now we're adding data from other CI systems, and so that approach wouldn't work at all. |
Yes, I have already created a bunch of |
Hello, Here is an updated report following our discussion yesterday:
ChangeLog:
|
I'd use |
@JenySadadia apart from what @padovan said, last time we also discussed adding the grafana dashboard link pointing to the failures in the build section. It will be great if you can add that too. |
We need to create a report for our ongoing work for of reporting stable-rc results with Greg KH.
The report will be sent to ourselves first. @crazoes is the main recipient.
Info given by @spbnick:
Here's a sample of notifications we send to Mark. It's sent an hour after last update to the revision.
Here's the code of his subscription: https://github.com/kernelci/kcidb/blob/main/kcidb/monitor/subscriptions/mark_brown.py
Here's the template entry point for notification body for revisions: https://github.com/kernelci/kcidb/blob/main/kcidb/templates/revision_description.txt.j2 (edited)
The text was updated successfully, but these errors were encountered: