Scheduling artifacts

By scheduling artifacts, you can automate pipeline executions based on pre-defined conditions. You can either:

Specify an artifact version to use.
Always select the latest version.

Creating a schedule

Base URL:

POST /v1/projects/{projectId}/schedules

You need to obtain the projectId using the following GET call: /v1/projects.

Read Data Productivity Cloud Public API for comprehensive reference material about each endpoint.

Default artifact selection

If no versionName is provided, the schedule will always use the latest deployed or promoted artifact in the specified environment.
The latest artifact is determined based on the most recent deployment or promotion, not by version name.

Schedules

Fixed artifact version

If a specific versionName is provided, the schedule will always trigger pipelines within that specific artifact version.

Variable overrides

Variable overrides allow you to dynamically adjust execution parameters when creating a schedule. This means that instead of relying solely on default or preset values within the artifact, you can define specific values at runtime, ensuring flexibility in different environments or scenarios.
When creating a schedule, you can pass variable overrides as part of the request body. These overrides will temporarily replace the values defined within the artifact for that particular execution.

Example request - schedule with variable overrides

curl --location --request POST 'https://abc.xyz.matillion.com/dpc/v1/projects/91697e59-87ad-4345-bc11-59352b432e5d/schedules' \
--header 'Authorization: Bearer YOUR_ACCESS_TOKEN' \
--header 'Content-Type: application/json' \
--data-raw '{
    "versionName": "About-version 2.0",
    "environmentName": "test-environment",
    "variableOverrides": {
        "var1": "customValue1",
        "var2": "customValue2"
    }
}'

Create a schedule with a version name

Request

curl --location --request POST 'https://abc.xyz.matillion.com/dpc/v1/projects/91697e59-87ad-4345-bc11-59352b432e5d/schedules?versionName=About-version 2.0&environmentName=testenvironment' \
--header 'Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJrdmRxeThOd0thZ05qYnZoUHljVkVCOXE4V0dTRTNEZmpfWDdla0hmYXEwIn...

Response

{
    "scheduleId": "ef097ecf-c130-4d9b-bfc5-ca888c8ad482"
}

Get schedule details using a schedule id

Request

curl --location --request GET 'https://abc.xyz.matillion.com/dpc/v1/projects/91697e59-87ad-4345-bc11-59352b432e5d/schedules/ef097ecf-c130-4d9b-bfc5-ca888c000000' \
--header 'Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJrdmRxeThOd0thZ05qYnZoUHljVkVCOXE4V0dTRTNEZmpfWDdla0hmYXEwIn00...

Response

{
    "pipelineName": "child job.orch.yaml",
    "scalarVariables": {
    "var1": "value1"
},

Preventing concurrent schedule executions

You can use the setting allowConcurrentExecutions enable concurrent executions. Manual use of this setting is optional and defaults to true if a value is not manually supplied.

If allowConcurrentExecutions = true: the schedule runs as normal, even if a previous execution is still running.
If allowConcurrentExecutions = false:
- If a previous execution is still running when the schedule is triggered again, the new execution is prevented.
- Once the previous execution finishes, the next scheduled run will proceed as normal.

Example request with allowConcurrentExecutions:

{
    "versionName": "About-version 2.0",
    "environmentName": "test-environment",
    "allowConcurrentExecutions": false
}