Triggering Runs from CI/CD

If a pipeline needs to kick off a Runner schedule and wait for the result — for example, running a KNIME workflow or shell script as part of a deploy — call the API directly instead of scripting the web UI. This guide triggers a schedule, polls until it finishes, and fails the pipeline if the run didn't pass.

Create a token

Create a Personal Access Token with Full Access scope — triggering a run is a write operation, so a Read Only token won't work. See Access Tokens for how to create one and where to store it as a pipeline secret.

Find the schedule ID

Open the schedule in Runner. The ID is the path segment right after /schedules/ in the browser's address bar — copy it from there.

Trigger the run

RUN_ID=$(curl -sf -X PUT "https://runner.example.com/api/schedule/$SCHEDULE_ID/run" \
  -H "Authorization: ApiKey $RUNNER_TOKEN" | jq -r '._id')

The response is the newly created run, including its _id and initial status of pending.

Poll until it finishes

while true; do
  STATUS=$(curl -sf "https://runner.example.com/api/run/$RUN_ID" \
    -H "Authorization: ApiKey $RUNNER_TOKEN" | jq -r '.status')

  case "$STATUS" in
    passed|failed|canceled) break ;;
  esac

  sleep 5
done

See Runs for what each status means. pending, running, and canceling are active states; passed, failed, and canceled are terminal — the loop above stops as soon as one of those is reached.

Fail the pipeline on a bad result

if [ "$STATUS" != "passed" ]; then
  echo "Run $RUN_ID finished with status $STATUS"
  exit 1
fi

Combine the three snippets into a single pipeline step, substituting your Runner host, $SCHEDULE_ID, and a $RUNNER_TOKEN secret from your CI system's variable store.