Skip to content
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

Views - Per Widget job filter #393

Open
k0machi opened this issue Jul 15, 2024 · 7 comments · May be fixed by #574
Open

Views - Per Widget job filter #393

k0machi opened this issue Jul 15, 2024 · 7 comments · May be fixed by #574
Assignees
Labels
enhancement New feature or request

Comments

@k0machi
Copy link
Collaborator

k0machi commented Jul 15, 2024

Add a per-widget setting to filter the jobs selected for a view, e.g. One test dashboard widget for rolling upgrades and one for longevity.

cc @roydahan @fruch

@fruch
Copy link
Contributor

fruch commented Aug 15, 2024

@k0machi

can you give a more concrete use-case for this one ?
we are talking about filter on building the view ? or when using it ?

@fruch
Copy link
Contributor

fruch commented Sep 23, 2024

@roydahan can you explain again what is the use case here ?

@roydahan
Copy link

The idea is that I can have 2 widgets, same or different one, but in one widget it'll filter only jobs x,y,z and in the second widget it will show jobs a,b,c.

@fruch
Copy link
Contributor

fruch commented Sep 23, 2024

The idea is that I can have 2 widgets, same or different one, but in one widget it'll filter only jobs x,y,z and in the second widget it will show jobs a,b,c.

Can you give a more concrete example when we might need such a thing, when is the filter from the whole view isn't enough ?

@roydahan
Copy link

e.g. the view I needed to build for each one of 2024.2 coordinator instead of 1 view with 3 widgets.
But also other things like graphs for some jobs in the future.

@fruch
Copy link
Contributor

fruch commented Sep 29, 2024

e.g. the view I needed to build for each one of 2024.2 coordinator instead of 1 view with 3 widgets.
But also other things like graphs for some jobs in the future.

If we have 3 plans, that we can show in one view, that would be good enough for this use case ?

@roydahan
Copy link

I don't understand the question.
I think that it should be possible to define filter per widget and use the same widget multiple times.
Only this way we can create meaningful views.

@k0machi k0machi added the enhancement New feature or request label Nov 18, 2024
k0machi added a commit to k0machi/argus that referenced this issue Jan 20, 2025
This commit implements per-widget entitity filtering for views,
allowing users to select which tests/groups/releases they want shown on
the widget in a specific view. To facilitate this, stat fetching has
been modified to accept widget id (position) of a view and then filter
tests accordingly. On the frontend side to facilitate conflict-free stat
fetching (for example from two TestDashboards) a hashmap has been
introduced to handle multiple stat objects and to dispatch them
correctly to each widget.

Caveats:
    * Release Planner views in general are not supported and contain
      several unwanted interactions:
        * If test dashboard is modified to filter anything, release
          planner stat bar will be gray (since there's no more anchor
          for it to get the stats from)
        * Anything version related will conflict
    * TestDashboard has a setting for a specific ScyllaVersion filter
      preset - this is not compatible and will make that filter set only
      output that version, which might be undesirable.
    * Aside from TestDashboard, currently no other widgets implement
      stat fetch, so filtering for them might not be interesting.
      However the widget will now receive filtered set of tests, which
      should make the performance summaries automatically support this
      feature.

Fixes scylladb#393
@k0machi k0machi linked a pull request Jan 20, 2025 that will close this issue
k0machi added a commit to k0machi/argus that referenced this issue Jan 23, 2025
This commit implements per-widget entitity filtering for views,
allowing users to select which tests/groups/releases they want shown on
the widget in a specific view. To facilitate this, stat fetching has
been modified to accept widget id (position) of a view and then filter
tests accordingly. On the frontend side to facilitate conflict-free stat
fetching (for example from two TestDashboards) a hashmap has been
introduced to handle multiple stat objects and to dispatch them
correctly to each widget.

Caveats:
    * Release Planner views in general are not supported and contain
      several unwanted interactions:
        * If test dashboard is modified to filter anything, release
          planner stat bar will be gray (since there's no more anchor
          for it to get the stats from)
        * Anything version related will conflict
    * TestDashboard has a setting for a specific ScyllaVersion filter
      preset - this is not compatible and will make that filter set only
      output that version, which might be undesirable.
    * Aside from TestDashboard, currently no other widgets implement
      stat fetch, so filtering for them might not be interesting.
      However the widget will now receive filtered set of tests, which
      should make the performance summaries automatically support this
      feature.

Fixes scylladb#393
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants