Project

General

Profile

Actions

Idea #8876

closed

[Workbench] Unify job and pipeline instance show tabs using Work Unit interface

Added by Brett Smith almost 8 years ago. Updated almost 8 years ago.

Status:
Resolved
Priority:
Normal
Assigned To:
Radhika Chippada
Category:
-
Target version:
Story points:
2.0

Description

Baseline: There is a single set of views (including partials) that renders the Status tab for both Jobs and Pipeline Instances. The UI is as close as possible to the existing Pipeline Instance status tab. It is implemented using the new Work Unit interface, so the same code can be used to render both Jobs and Pipeline Instances, without conditional branches based on the type of object being rendered.

Follow the structure in #8651-3 to implement work unit proxies for job and pipeline instance.

These methods need to be implemented in the Work Unit interface, and will generally have different implementations for jobs and pipeline instances:

  • modified_by_user_uuid
  • created_at
  • started_at
  • finished_at
  • state_label (a string to show to the user, like "Queued" or "RunningOnServer" -- this method does not try to translate states to a lowest-common-denominator set of states, or anything like that)
  • state_bootstrap_class (a class like "danger", "success", or "warning" that a view can use directly to make a display class like <span class="badge badge-success" ...>
  • success? -- true if the work unit finished successfully, false if it has a permanent failure, and nil if the final state is not determined.
  • progress (a number between 0 and 1)
  • log_collection -- uuid or pdh with saved log data, if any. (Log rendering is explicitly not part of this story.)
  • label -- for either jobs or pipeline instances, when they're the top-level thing you're looking at, the label is the name. Otherwise, it comes from the object's components field. This is assigned when the work unit is created (see #8647).
  • components -- an array of work unit objects

Both work units also need the following methods, which are expected to return nil for pipeline instances because they're not relevant:

  • parameters
  • script
  • script_repository
  • script_version
  • supplied_script_version
  • docker_image
  • runtime_constraints
  • priority
  • nondeterministic
  • output

Still needs discussing: control. Canceling jobs, canceling pipeline instances, pausing and unpausing pipeline instances.

  • can_cancel? -- should we offer the user a "cancel" button?
  • cancel
  • can_pause? -- should we offer the user a "pause" button?
  • pause

Suggest two partial views: "this is the thing being displayed," "this is a child being displayed." Job and pipeline instance views just call those partials to do their work.

Jobs show controller will get the job, get its work unit, then render the work unit view for this job's component. Same goes for pipeline instance controller.


Subtasks 1 (0 open1 closed)

Task #9207: Review branch 8876-work-unitResolvedTom Clegg05/25/2016Actions

Related issues

Related to Arvados - Idea #9312: [Workbench] Job children display using the new work_unit strategyClosedActions
Actions

Also available in: Atom PDF