# Available workflow implementations

Most workflows are mainly useful as sub-workflows of a more complex workflow. The workflow that you are most likely to use directly is the debian_pipeline workflow.

As a user, you cannot directly execute a workflow implementation; instead, you start them through a workflow template, which provides some default settings and restricts those that you can set. These are configured by Debusine instance admins, and are listed on the Workspace’s details page. (e.g. for debusine.debian.net).

- Workflow `autopkgtest`
- Workflow `blhc`
- Workflow `create_child_workspace`
- Workflow `debdiff`
- Workflow `debian_pipeline`
  - When `enable_regression_tracking` is set
- Workflow `lintian`
- Workflow `make_signed_source`
- Workflow `noop`
- Workflow `package_publish`
  - Permission considerations
  - Resource accounting considerations
  - Workflow definition
- Workflow `package_upload`
- Workflow `piuparts`
- Workflow `qa`
  - Behavior with `update_qa_results` set to True
  - Behavior with `enable_regression_tracking` set to True
  - Handling of `fail_on`
- Workflow `reverse_dependencies_autopkgtest`
- Workflow `sbuild`
- Workflow `update_environments`
- Workflow `update_suite`
- Workflow `update_suites`
  - Key generation stage
  - Main stage

# Runtime status workflows

The runtime status can have the following values (order of checks matters here, first match defines the status):

- “Needs input”: there’s at least one child work request with task type WAIT and status == RUNNING where `workflow_data['needs_input']` is true.

- “Running”: there’s at least one child work request with task type != WAIT and status == RUNNING.

- “Waiting”: there’s at least one child work request with task type WAIT and status == RUNNING where `workflow_data['needs_input']` is false.

- “Pending”: there’s at least one child work request where status == PENDING.

- “Blocked”: there’s at least one child work request where status == BLOCKED.

- “Aborted”: there’s at least one child work request where status == ABORTED.

- “Completed”: all the child work requests are in status COMPLETED.

The runtime status is accessible via `workflow.workflow_runtime_status`.