Story #8876

Updated by Brett Smith over 4 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 may have different implementations for jobs and pipeline instances:

* modified_by_user_uuid
* created_at
* started_at
* finished_at
* Some kind of @state@ that returns one of the following states: Queued, Running, Stopped. Or maybe it returns a more direct display hint - a Bootstrap badge, or a color to 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 method to indicate where there are logs, if any. (Log rendering is explicitly not part of this story.)
* A @label@ 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.
* A @components@ 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_repository
* script_version
* supplied_script_version
* docker_image
* runtime_constraints
* priority
* nondeterministic
* output

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.