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