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

Job separation on summary page #44

Open
nigelbabu opened this issue Aug 13, 2018 · 4 comments
Open

Job separation on summary page #44

nigelbabu opened this issue Aug 13, 2018 · 4 comments

Comments

@nigelbabu
Copy link
Contributor

The final ask (for now) is to possibly look at a column or separation around job. This is useful to understand what failed with mux vs non-mux (for starters) and once we can list by jobs, or add job based columns it may become easier.

@ShyamsundarR
Copy link

The intention is the be able to query the failure database in different ways, for example,

  • show all tests in that failed in line-coverage jobs
  • Or, replace the above with mux/non-mux

The intention is the be able to arrive at failures that are specific to a type of job, or to at least get to those faster. Also, it looks like each failure stores which job it failed, from, hence requesting the ability to extend the frontend to provide reports of the same nature.

@nigelbabu
Copy link
Contributor Author

@ShyamsundarR Should I list all the jobs by name? Or do you want me to do some pre-defined grouping? For example line-coverage, mux, non-mux? (Or both?)

@atinmu
Copy link

atinmu commented Aug 21, 2018

I'd vote for having both the approaches.

@ShyamsundarR
Copy link

Let me answer this by expanding on the request to give an idea about what we may want in the future,

  • Curent query is: date-range && branch
  • Future query can be: "date-range && (branch || job || node || has-bugs || ...)"

I am unsure how the UI will look/evolve, but the idea is to be able to literally generate a free form query and get a list.

The above should solve all issues as I see it, grouping/values for each of the above fields would depend on all unique values in the filed (I guess) so pre-defined groups may not be needed?

nigelbabu added a commit that referenced this issue Aug 24, 2018
* Switch the JS stuff to be more generic and modern
* Add a job list to the filters
* Updates #44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants