Idea #8876
Updated by Brett Smith almost 8 years ago
Baseline: There is a single set of views (including partials) that renders the Status Job show tab for both Jobs and Pipeline Instances. The UI is as close as possible to becomes more like the existing Pipeline Instance status show tab. It This 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. how it renders child work units. Follow the structure in #8651-3 #8651 to implement work unit proxies for job and pipeline instance. These methods need to be implemented in the Work Unit interface, implemented, 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 <code><span class="badge badge-success" ...></code> * @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: 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.