action #71977

Include currently running jobs in jobs overview API call

Added by ph03nix 10 months ago. Updated 10 months ago.

Feature requests
Target version:
Start date:
Due date:
% Done:


Estimated time:


Currently, when performing a jobs overview API call (e.g., 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.


#1 Updated by ph03nix 10 months 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.

#2 Updated by okurz 10 months 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 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 :)

#3 Updated by ph03nix 10 months ago

Hi Oliver,

thanks for looking into this. /api/v1/jobs looks like a possible workaround. Especially something like 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.

#4 Updated by okurz 10 months ago

  • Assignee deleted (okurz)

alright. Thanks for the clarification.

Also available in: Atom PDF