Add worker info in job_next_previous

[ggardet]

This PR adds a Worker column to know which worker was used.

Screenshot:

[ggardet]

It would make more sense to show the worker's host name and instance number as link text because the ID is rather random.

That was my original idea, but I still need to figure out how to retrieve the name.

You could also already make the href server-side using the url_for helper of Mojolicious.

I will have a look.

[ggardet]

PR updated to use worker name instead of worker id, based on @kalikiana suggested change. (Thanks!)

[Martchus]

Another alternative: We could include at least a link to the worker's page as the worker ID is available (without doing any further queries or joins). Since the link wouldn't have a meaningful text (just the worker ID) it could be in form of an icon.

[okurz]

That alternative suggestion sounds good to me. A good compromise UX- and performance wise

[ggardet]

It does not make much sense to have it in investigation tab since you cannot reach it when the test is green.

I need to investigate how to add a checkbox for this optional column.

[Martchus]

Having an optional column might not be that easy (depending how well DataTables supports that). So maybe just go for an icon-link as suggested in my previous comment.

[ggardet]

Having an optional column might not be that easy (depending how well DataTables supports that). So maybe just go for an icon-link as suggested in my previous comment.

Worker ID was my initial submission but this is far less useful than worker name. Maybe we can build a table to translate worker ID to worker name.

[Martchus]

but this is far less useful than worker name.

If it is a link to the worker details page of that specific worker it is still an improvement.

Maybe we can build a table to translate worker ID to worker name.

We have that table, it is the workers table. And accessing the worker via …->assigned_worker->.… will automatically do a query to that table. The problem is just that doing this query for every job will likely have a notable impact on the response time (and so far you haven't shown any figures which suggest otherwise). I've already proposed to do a join (or sub query) in the initial query for jobs. It would still be slower but likely the database will be able to handle it efficient enough internally and we'd still only do one query. However, doing that definitely requires some playing around with DBIx and the raw SQL we use.

[perlpunk]

#5043 optimizes the existing next/previous route with prefetching job modules and dependencies. We could try out the same with workers and see how it performs.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.