Project

General

Profile

Idea #8876

Updated by Tom Clegg about 8 years ago

Baseline: Job show tab becomes more like the Pipeline Instance show tab.    This is how it renders child work units. 

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

 These methods need to be implemented, and will generally may have different implementations for jobs and pipeline instances: 

 * @modified_by_user_uuid@ modified_by_user_uuid 
 * @created_at@ created_at 
 * @started_at@ started_at 
 * @finished_at@ finished_at 
 * @state_label@ (a string to show to Some kind of @state@ that returns one of the user, like "Queued" or "RunningOnServer" -- this method does _not_ try to translate states to following states: Queued, Running, Stopped.    Or maybe it returns a lowest-common-denominator set of states, more direct display hint - a Bootstrap badge, or anything like that) 
 * @state_bootstrap_class@ (a class like "danger", "success", or "warning" that a view can use directly color to make a display class like <code class="html">&lt;span class="badge badge-success" ...&gt;</code> render that badge.    Or maybe we have multiple methods.    This needs hashing out. 
 * A @success?@ -- method that returns 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) progress 
 * @log_collection@ -- uuid or pdh with saved log data, A method to indicate where there are logs, if any.    (Log rendering is explicitly not part of this story.) 
 * A @label@ -- for method.    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). 
 * A @components@ -- an array of work unit method that returns real objects in a ??? (Array?    Hash?) 

 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 
 * @script_repository@ script_repository 
 * @script_version@ script_version 
 * @supplied_script_version@ supplied_script_version 
 * @docker_image@ docker_image 
 * @runtime_constraints@ runtime_constraints 
 * @priority@ priority 
 * @nondeterministic@ nondeterministic 
 * @output@ 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@ 

 Have a work unit model, directory, and views.    Maybe the views are only partials.    Two partials: "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.

Back