Django Models for Workflow Registry

class workflow_reg.models.AbstractClass(*args, **kwargs)[source]

Abstract class containing columns appearing in all tables. Keeps information on who and when created or updated a DB entry. All following models extend this class

class workflow_reg.models.DockerEnv(*args, **kwargs)[source]

Represents a docker container. Each DB entry is identified as unique based on the docker name and tag.

The user initially gives a name, tag, dockerfile and if he/she wishes additional docker scripts (if used inside the Dockerfile). Once a container is registered, the platform’s admin checks the files and builds a docker image. This image should be publicly available and the url field should be updated accordingly once the image is built and available.

exception DoesNotExist
exception MultipleObjectsReturned
get_scripts()[source]

Method to retrieve all the scripts associated with a specific docker container

Returns

list: list of scripts associated with the specific docker container object instance.

get_workflows()[source]

Method to retrieve all the workflows associated with a specific docker container

Returns

list: list of workflows associated with the specific docker container object instance.

class workflow_reg.models.DockerScript(*args, **kwargs)[source]

This class is associated with a DockerEnv DB entry. Represents an additional script used by a Dockerfile.

Instances of this class can be created either with a DockerEnv creation or separately, where one by one the scripts should be registered in the DB. The script is characterized based on the associated DockerEnv and its own name.

exception DoesNotExist
exception MultipleObjectsReturned
class workflow_reg.models.Workflow(*args, **kwargs)[source]

Workflow class represents a CWL workflow. In this table, only the CWL characterized as workflows are registered. Each workflow is unique based on its name and version. The user should provide a name, version, the name of the spec yaml file, the two files (i.e. the workflow file and the spec file) as well as a related DockerEnv where the workflow will be executed.

It is possible to provide the CWL files used inside the CWL workflow (i.e. those that contain a Command Line instead of a workflow). These files are represented by the WorkflowPart class. However, if the additional CWL files are not provided upon a Workflow object creation, users can register them afterwards one by one.

exception DoesNotExist
exception MultipleObjectsReturned
class workflow_reg.models.WorkflowPart(*args, **kwargs)[source]

This class represents a CWL file, part of a CWL workflow (kind CommandLineTool for example). Each object should be associated with a Workflow instance and should have a name, version and a spec yaml file.

CWL workflow parts can be registered at the same time with their parent workflow or afterwards using the WorkflowPartView

exception DoesNotExist
exception MultipleObjectsReturned