Skip to content

Enable find jobs by fleet_id in backoffice - #2474

Open
Alberto Vilches (avilches) wants to merge 11 commits into
mainfrom
worktree-admin-job-runner-fleet-search
Open

Enable find jobs by fleet_id in backoffice#2474
Alberto Vilches (avilches) wants to merge 11 commits into
mainfrom
worktree-admin-job-runner-fleet-search

Conversation

@avilches

@avilches Alberto Vilches (avilches) commented Sep 9, 2026

Copy link
Copy Markdown
Contributor

Summary

Reworks every column of the job list in the admin backoffice, and lets its search box match by fleet_id and by compute profile (with a background index on fleet_id so that search stays fast). Clicking a value reloads the job list with the search box filled in with that value, so the visible search field always says what you are looking at.

Column by column:

  • Id: the job UUID, shortened to 12 characters as a grey monospace chip with the full value in the tooltip. The only link in the row that opens the job's edit page.
  • Author: the username, and the instance CRN on a smaller second line. Both search the list for that value.
  • Program: the function name, with "Provider: name" on a second line, or "Custom" when the function has no provider. The function name and the provider name each search the list for themselves.
  • Status: the same coloured badge as before, now searching the list for that status.
  • Fleet Id: the engine job id as the same kind of chip (fleet_id for Fleets, ray_job_id for Ray), with the Code Engine project and region below it for Fleets jobs and the word Ray for Ray ones. Nothing is drawn when the job has no engine id yet.
  • Compute Profile: the compute profile, searchable on click, with the function size name below it. Empty for Ray jobs.
  • Created and Updated: YY/MM/DD hh:mm:ss on a single line, still sortable by clicking the header.

Details and comments

fleet_id had no index before, so the migration uses PostgreSQL's CREATE INDEX CONCURRENTLY to avoid locking api_job while it builds. It falls back to a plain index on non-PostgreSQL backends, since the test suite runs against SQLite.

The clickable values fill in the changelist's own search box (?q=...) rather than an exact-match filter, so they are covered by search_fields (added status, instance_crn, program__provider__name and compute_profile_fk__compute_profile_id on top of the existing ones). An end-to-end test hits the real changelist with each of these search terms and checks the job is still in the results.

image

@avilches
Alberto Vilches (avilches) marked this pull request as ready for review September 10, 2026 17:59
@avilches
Alberto Vilches (avilches) requested a review from a team as a code owner September 10, 2026 17:59
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

Successfully merging this pull request may close these issues.

1 participant