Scheduling artifacts via the API

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 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",
    "scalarVariables": {
        "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
}