-
Notifications
You must be signed in to change notification settings - Fork 376
More canned queries (Runfo queries) in query documentation #10034
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
Conversation
| let type = ""; // Optional: warning or error | ||
| let jobName = "Build_Windows_Release"; // Optional: Issues associated with jobs with this name | ||
| let taskName = ""; // Optional: Issues associated with tasks with this task name | ||
| TimelineIssues |
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 passes some duplicate rows. It's a bit easier to notice if you change the order by to | order by BuildId, Path.
I think this is just due to duplicates in the TimelineRecords table? Ignoring it is not a huge deal (a human can just deal with it). I'll have to think a bit about how to modify the query to eliminate them (a big ol' summarize would do it but... oof).
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 assume it's the attempts (or ingestion retries). If we read a build that's failed, and it get retried afterward, I think we get a second row. I'm not sure what we write down that stuff?
dougbu
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.
Great additions❕ My comments are all nits and questions
Co-authored-by: Doug Bunting <[email protected]>
Co-authored-by: Doug Bunting <[email protected]>
Co-authored-by: Doug Bunting <[email protected]>
Co-authored-by: Doug Bunting <[email protected]>
|
|
||
| ## What is the data? | ||
|
|
||
| The data that we collect is only a subset of tests that run and not every test that runs. **We've chosen to collect results of tests that have failed in the last 90 days**. We assume that tests that are always passing or have continued to pass after 90 days are no longer interesting to look at, and thus, their results are no longer collected. |
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.
As a point of reference runfo only collects 14-21 days of test data. The logic being that after 14 days the corresponding AzDO build is gone hence data from further back is probably not actionable as you can't even see the build anymore. Thus far 14 days has been enough. I've only had 1-2 requests for data further back and it ended up not being necessary.
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 don't agree the information provided here is unactionable @jaredpar. The runfo limit doesn't make as much sense for these Kusto queries because runfo dealt only w/ the public AzDO project. These queries are also used for analytics, where AzDO can display 180d of data. And Kusto stores enough details for the results to be useful (in many cases) without the builds themselves.
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.
Thanks for the input, Jared. This data is used for more than replicating Runfo queries, such as to track trends of flaky tests or other "interesting" tests (e.g. with the chi-squared statistical analysis), so we feel that 90 days is sufficient for that.
To double check:
For issue: #9537