[feat] AB comparison - #2018
Conversation
1d1ea9d to
67cd6e4
Compare
fb3fad6 to
61911e9
Compare
37060e1 to
43aaabb
Compare
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
Signed-off-by: Felipe Bergamin <felipebergamin@profusion.mobi>
Introduce compare response models and SQL filter helpers used by the summary and diff endpoints, including post-join status filtering. Signed-off-by: Felipe Bergamin <felipebergamin@profusion.mobi>
Add checkout-scoped SQL for status aggregates, change-count categories, and builds/boots/tests row diffs with a shared identity key. Signed-off-by: Felipe Bergamin <felipebergamin@profusion.mobi>
Wire compare routes for summary counts and builds/boots/tests diffs, with request scripts and OpenAPI schema updates. Signed-off-by: Felipe Bergamin <felipebergamin@profusion.mobi>
Define compare search/state types, React Query fetchers, and helpers to map API rows into change categories for the breakdown tables. Signed-off-by: Felipe Bergamin <felipebergamin@profusion.mobi>
Add revision selectors, summary matrix, change-filter chips, and virtualized builds/boots/tests tables for the compare page. Signed-off-by: Felipe Bergamin <felipebergamin@profusion.mobi>
Assemble the compare page, register routes, and link it from tree details so users can open an A/B revision comparison. Signed-off-by: Felipe Bergamin <felipebergamin@profusion.mobi>
Cover the compare page happy path with mocked commits, summary, and builds diff responses. Signed-off-by: Felipe Bergamin <felipebergamin@profusion.mobi>
Signed-off-by: Felipe Bergamin <felipebergamin@profusion.mobi>
840099f to
2fdf8d0
Compare
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