Workflows and WorkflowRuns¶
Object model and basic user interface¶
The Workflow component contains the following high-level object models: Workflow, WorkflowVersion, WorkflowFile, WorkflowRun, WorkflowRunDataset, WorkflowRepository, PublishedWorkflow, and Repository.
Workflows and WorkflowRun¶
Figure 1: Object model of Workflow, WorkflowVersion, WorkflowFile, WorkflowRun, Repository
The overall object model is visible in Figure 1 and is briefly described here:
-
A Workflow can be created from scratch or imported (e.g., from git). When workflows are imported, is_remote is set to true and the remote_repository stores the workflow's original URL.
-
A Workflow contains one to multiple WorkflowVersions.
-
Each WorkflowVersion contains one or more WorkflowFiles, with each WorkflowFile having a type from a predefined list (main, config, test). A WorkflowVersion must define at least one WorkflowFile. For Publishing (described later), a WorkflowFile of type "main" that represents the workflow entry point must exist.
-
A WorkflowFile is linked to the WorkflowVersion. Between WorkflowVersions, the file data type can be different for files with the same path.
-
A WorkflowFile type can be changed regardless of the "commit" state of the WorkflowVersion.
-
A WorkflowRun represents a particular execution of a WorkflowVersion and links to the existing Dataset model through a WorkflowRunDataset that qualifies the relationship between the WorkflowRun and the Dataset with a type (input, output, config, report, log).
Integration with git¶
WorkflowFiles are stored on disk and are placed in a git repository local to the LabID instance. When the WorkflowVersion is "released," a git "commit" is performed and the hash is stored in the WorkflowVersion. Once released, a new version can be created. This new version is created without a commit hash, allowing new or updated files to be uploaded.
For information about configuring restricted git repositories, please see the SSH Keys administration documentation.