Verentis

Triggers & schedules

Triggers & schedules

Run your engine automatically — on a cron schedule, or in response to file changes in the workspace.

Engines don't only run when a user clicks Run. With the scheduled and event-driven execution modes, your engine runs automatically.

Enabling automatic runs

Declare the modes your engine supports:

spec:
  execution-modes:
    - request-response
    - scheduled
    - event-driven

The schedule and trigger definitions themselves live as manifests in the workspace VFS (the same install-by-file model used everywhere). Adding the manifest creates the rule; removing it deletes it.

Schedules (cron)

A schedule runs your engine on a cron expression — for example a nightly report or an hourly sync.

api-version: verentis.io/v1
kind: ExecutionSchedule

metadata:
  name: nightly-report
spec:
  engine: python
  target: /scripts/report.py
  cron: "0 2 * * *"          # 02:00 every day
  run-as:
    service: reporting-bot   # the workspace service the run acts as
cronstring

Standard cron expression for when to run.

engine / target

Which engine to run and the file it operates on.

run-as.service

The workspace service the run acts as. Automated runs use a service principal, not a user.

Triggers (file changes)

A trigger runs your engine when files change in the workspace — for example, process every CSV dropped into a folder.

api-version: verentis.io/v1
kind: ExecutionTrigger

metadata:
  name: process-uploads
spec:
  engine: python
  on:
    - path: /incoming/**
      events: [created, updated]
  run-as:
    service: ingest-bot
on[].path

A path or glob to watch in the VFS.

on[].events

Which change events fire the trigger (e.g. created, updated).

run-as.service

The service the triggered run acts as.

Triggers can fire more than once per change

A single upload can produce multiple change events (for example a create plus a head update). Make your engine idempotent: running it twice for the same input should be safe and produce the same result.

run-as and identity

Scheduled and triggered runs have no signed-in user, so they act as a service principal — a workspace service you reference by name. The platform resolves that name to a stable service identity and mints a scoped token for the run. Give automated work a dedicated service with only the scopes it needs.

Derived service identity

A workspace service has a deterministic identity derived from the workspace and the service name, so the platform can resolve run-as.service without a lookup. Keep service names stable.

Next

Testing your engine

Test your logic, container and manifest before you publish.

Platform APIs & auth

Authenticate and call the Verentis API.