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
  require>: another_workflow
# another_workflow.dig
  sh>: tasks/


  • require>: NAME

    Name of a workflow.


    require>: another_workflow
  • session_time: ISO_TIME_WITH_ZONE


    require>: another_workflow
    session_time: 2017-01-01T00:00:00+00:00
    timezone: UTC
      monthly>: 1,09:00:00
      loop>: ${moment(last_session_time).daysInMonth()}
        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.


      require>: child
        param_name1: ${parent_param_name}


  • 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>.