action #71977
openInclude currently running jobs in jobs overview API call
0%
Description
Currently, when performing a jobs overview API call (e.g. https://openqa.suse.de/api/v1/jobs/overview?test=mau-filesystem), the API returns only completed tests and skips currently running ones:
Here all SLE15 and some SLE12 variants are missing, because they are running at the moment. This is not nice, as it prevents this API call to be used for searching for the latest run of a certain test (e.g. search latest mau-filesystem tests)
Hence my suggestion to modify the API to include the currently running ones as well.
Furthermore I suggest to also add a parameter (e.g. state=completed), where one can select if we want the currently running ones, or the last completed ones - e.g.
- https://openqa.suse.de/api/v1/jobs/overview?test=mau-filesystem - returns all runs including the currently running ones
- https://openqa.suse.de/api/v1/jobs/overview?test=mau-filesystem&state=completed - return all runs but post the state of the last completed run instead of the currently ongoing ones
Files
Updated by ph03nix over 3 years ago
To illustrate why this is useful:
For the verification runs we find all completed tests of mau-filesystem for all SLE variants. I use this API call for it, but end most of the times up with an incomplete list.
Updated by okurz over 3 years ago
- Assignee set to okurz
- Priority changed from Normal to Low
- Target version set to future
You made a good observation. Originally the api route /api/v1/jobs/overview was introduced as part of https://github.com/os-autoinst/openQA/pull/1651 motivated by #33892 . There is the route /api/v1/jobs which can be used for querying based on a broader range of parameters. Maybe this route already gives you a better starting point?
Regarding the feature request in particular: I consider it valid but consider it of "Low" priority because based on my current understanding the functionality is already available but over different routes, e.g. the "jobs" route itself. And anything that has a workaround available is a good candidate for "Low". (Why "future"? Well, that's because our current backlog is 104 tickets when our target is <= 100 and I am considering our current team velocity and the state of the project, e.g. stability of tests. This makes me think that implementing any new feature that closely touches existing functionality can be more costly than originally anticipated). I am happy to be convinced otherwise, e.g. in case this is not just a "would be nice" but for example a big cost saver for you :)
Updated by ph03nix over 3 years ago
Hi Oliver,
thanks for looking into this. /api/v1/jobs looks like a possible workaround. Especially something like https://openqa.suse.de/api/v1/jobs?test=mau-filesystem&state=done should do the job.
Superficially looking at /api/v1/jobs, it returns a whole history of jobs, it's a lot slower than /api/v1/jobs/overview. So it would be still fancy to have it solved via jobs/overview in some way, but understandably as low priority ticket, when this is possible. Definitely just a "would be nice to have" feature request.