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.

Copy
Copied
# workflow1.dig
+step1:
  require>: another_workflow
Copy
Copied
# another_workflow.dig
+step2:
  py>: tasks.step2

Options

  • require> : NAME

    Name of a workflow.

    Examples:

    Copy
    Copied
    require>: another_workflow
  • session_time : ISO TIME WITH_ZONE

    Examples:

    Copy
    Copied
    require>: another_workflow
session_time: 2017-01-01T00:00:00+00:00
    Copy
    Copied
    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 projectid or projectname. If the project does not exist, the task will fail. If you set both projectid and projectname, the task will fail.

    Examples 1:

    Copy
    Copied
    require>: another_project_wf
project_id: 12345

    Examples 2:

    Copy
    Copied
    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.

    Copy
    Copied
    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:

    Copy
    Copied
    +example:
require>: child
params:
  param_name1: ${parent_param_name}

Notes

  • require> has been changed to ignore inherited retryattemptname parameter. digdag retry command generates unique retry attempt name to run, but it is not passed to require>.