ui: fix long loading times on /jobs/:jobId page

[ChaiWithJai]

This PR is part of resolving 14787.

This PR does not solve long loading times on the jobs.index route. I believe we can and should use pagination and we can also patch 10555 while we do that to keep PRs small.

[github-actions]

Ember Asset Size action

As of df5825d

Files that got Bigger 🚨:

File	raw	gzip
nomad-ui.js	+130 B	+56 B

Files that stayed the same size 🤷‍:

File	raw	gzip
vendor.js	0 B	0 B
nomad-ui.css	0 B	0 B
vendor.css	0 B	0 B

[github-actions]

Ember Test Audit comparison

	main	df5825d	change
passes	1427	1425	-2
failures	0	2	+2
flaky	0	0	0
duration	11m 27s 561ms	000ms	-11m 27s 561ms

[djenriquez]

Hi @ChaiWithJai, I'm looking at creating a local branch where I merge v1.5.3 into this branch (since thats the release we're on internally). Do you foresee any incompatibilities with that?

[ChaiWithJai]

Hi @ChaiWithJai, I'm looking at creating a local branch where I merge v1.5.3 into this branch (since thats the release we're on internally). Do you foresee any incompatibilities with that?

Merging this branch might not be suitable for your needs as it does not solve the problem for the jobs.index page (The main Jobs list page). And I think that @philrenaud solves this same from this PR in his current block of work which we'll be out soon.

[djenriquez]

Hi @ChaiWithJai, I'm looking at creating a local branch where I merge v1.5.3 into this branch (since thats the release we're on internally). Do you foresee any incompatibilities with that?

Merging this branch might not be suitable for your needs as it does not solve the problem for the jobs.index page (The main Jobs list page). And I think that @philrenaud solves this same from this PR in his current block of work which we'll be out soon.

Ok, just to confirm, theres a PR that exists which we think will handle the problems in GH-14787?

[philrenaud]

Hi @djenriquez — the PR that Jai is referring to is #17214 but that doesn't solve for the slow index page issue of #14787 — it's meant to make child jobs specifically less painful to use within the UI, but won't impact the /jobs index page.

The correct solution for that is for us to paginate jobs index requests; we're working on setting that up but have some plans to depend on the unpaginated "all jobs" request for some upcoming features. As of now, the plan is to set up a new "all jobs' summaries" request, and to use a paginated jobs request otherwise.

This seems like something worth prioritizing, so we'll kick off work related to it soon. We appreciate your patience on this!

[djenriquez]

Completely understood @philrenaud , thank you for the reply.

[philrenaud]

Made less necessary with the work in #20452