[feat] AB comparison - #2018
Conversation
1d1ea9d to
67cd6e4
Compare
fb3fad6 to
61911e9
Compare
18df37d to
7c275a0
Compare
Signed-off-by: Felipe Bergamin <felipebergamin@profusion.mobi>
Closes kernelci#2023 Signed-off-by: Felipe Bergamin <felipebergamin@profusion.mobi>
Closes kernelci#2009 Signed-off-by: Felipe Bergamin <felipebergamin@profusion.mobi>
…akdown Part of kernelci#2010 kernelci#2011 kernelci#2012 Signed-off-by: Felipe Bergamin <felipebergamin@profusion.mobi>
Signed-off-by: Felipe Bergamin <felipebergamin@profusion.mobi>
Signed-off-by: Felipe Bergamin <felipebergamin@profusion.mobi>
37060e1 to
43aaabb
Compare
Use bare-array payloads and latest-wins collapse for all three detail endpoints, with aligned SQL filters and no Python dual path. Signed-off-by: Felipe Bergamin <felipebergamin@profusion.mobi>
One-sided A/B transitions were misclassified as fixed/regression; classify them correctly and document each transition status next to the filter bar.
Signed-off-by: Felipe Bergamin <felipebergamin@profusion.mobi>
Boots and tests share build architecture in the diff identity and API so listing tables can show arch alongside path and hardware.
f0d3eee to
840099f
Compare
|
Just to document the comments from the Working Group.
|
| issues."_timestamp" DESC | ||
| """ | ||
|
|
||
| print(query) |
| return rows | ||
|
|
||
|
|
||
| def get_tree_compare_data( |
There was a problem hiding this comment.
I believe this shoudl no longer be needed now that we are splitting the endpoints, right?
| return True | ||
| filtered_issues = filters.filterIssues.get(filter_type, set()) | ||
| if filtered_issues and not known_issues.issubset(filtered_issues): | ||
| if filtered_issues and known_issues.isdisjoint(filtered_issues): |
There was a problem hiding this comment.
are these real changes, or just needing rebase?
| const shortA = hashA.slice(0, SHORT_HASH_LENGTH) || '—'; | ||
| const shortB = hashB.slice(0, SHORT_HASH_LENGTH) || '—'; | ||
|
|
||
| const mock = COMPARE_FAILURES_MOCK; |
| if (statusB === 'PASS') { | ||
| return 'newPass'; | ||
| } | ||
| return 'appeared'; |
There was a problem hiding this comment.
we need to think a little bit in the nomenclature, in 'appeared' we would expect to also include the new pass and new failure.
Also, I might be wrong, but I believe we have some divergence on some cases when comparing this implementation and _CHANGE_COUNT_SELECT.
For instance, pass -> inconclusive here would be considered regression and fail -> inconclusive would be considered fixed. That is not the case on the _CHANGE_COUNT_SELECT.
There was a problem hiding this comment.
Just to have some clarity, this is how I interpret the filters shown today. Do we have the feature specification in a .md file? Could be good to elevate the discussions to a higher level, since we are struggling with code review anyway
| A | B | Alias |
|---|---|---|
| Red | Green | Fixed |
| (!Green) | Green | New passes |
| Green | Red | Regression |
| (!Red) | Red | New failures |
| Red | Red | Still failing |
| None | (!None) | Appeared |
| (!None) | None | Disappeared |
Note that I don't count MISS as None, but that might require discussion
There was a problem hiding this comment.
Talking about high level ideas, I wonder how users would react to having a form with 2 multi-select fields: FROM and TO. This wouldn't allow to select specific pairings... which leads me to a more complex idea: a form that allows to select multiple (from, to) pairs
3 participants
Description
Implementations to AB comparison detailed information.
Note
We are still discussing about the design and UX so it is probably going to change.
Any comments/suggestions will be welcome. :)
Visual reference
Gravacao_de_tela_20260804_141527.webm