require>: Depends on another workflow

require> operator requires completion of another workflow. This operator is similar to call> operator, but this operator doesn't start the other workflow if it's already running or has done for the same session time of this workflow. If the workflow is running or newly started, this operator waits until it completes. In addition, require operator can kick the another project's workflow.

# workflow1.dig
+step1:
  require>: another_workflow

# another_workflow.dig
+step2:
  py>: tasks.step2

Options

require>: NAME
Name of a workflow.
Examples:

  require>: another_workflow

session_time: ISO_TIME_WITH_ZONE
Examples:

  require>: another_workflow
  session_time: 2017-01-01T00:00:00+00:00

  timezone: UTC

  schedule:
    monthly>: 1,09:00:00

  +depend_on_all_daily_workflow_in_month:
    loop>: ${moment(last_session_time).daysInMonth()}
    _do:
      require>: daily_workflow
      session_time: ${moment(last_session_time).add(i, 'day').format()}

project_id: project_id
project_name: project_name
You can kick another project's workflow by setting project_id or project_name. If the project does not exist, the task will fail. If you set both project_id and project_name, the task will fail.
Examples 1:

  require>: another_project_wf
  project_id: 12345

Examples 2:

  require>: another_project_wf
  project_name: another_project

rerun_on: none, failed, all (default: none)
rerun_on control require> really kicks or not if the attempt for the dependent workflow already exists.
- none ... Not kick the workflow if the attempt already exists.
- failed ... Kick the workflow if the attempt exists and its result is not success.
- all ... require> kick the workflow regardless of the result of the attempt.
ignore_failure: BOOLEAN
This operator fails when the dependent workflow finished with errors by default.
But if ignore_failure: true is set, this operator succeeds even when the workflow finished with errors.

  require>: another_workflow
  ignore_failure: true

require> evaluates ignore_failure at last of its process. If rerun_on is set and require> run new attempt, the result of new attempt is checked.

params: MAP
This operator doesn't pass a parameter to another workflow. params options set parameters.
Examples:
```
+example:
  require>: child
  params:
    param_name1: ${parent_param_name}
```


## Notes
- require> has been changed to ignore inherited *retry_attempt_name* parameter.
  `digdag retry` command generates unique retry_attempt_name to run, but it is not passed to require>.

require>: Depends on another workflow

Options

Was this helpful?