mirror of
https://github.com/windmill-labs/windmill.git
synced 2026-08-20 08:01:35 +00:00
Ruben Fiszel
136c88a231
* docs(skills): decouple safe local commands from destructive sync push The schedules, triggers, and resources skill templates lumped every CLI command under a blunt "do NOT run them yourself" directive. This conflated two very different risk profiles and forbade the agent from running even read-only/local commands, creating needless friction. Align these three with the nuanced policy flow-cli.md already uses: keep `wmill sync push` defensive (it deploys and can be destructive to remote state — only run when the user explicitly asks to deploy/publish/push), while letting read-only commands (`sync pull`, `schedule`, `resource list`) be run freely. Regenerated auto-generated skills + skills.gen.ts. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * feat(cli): warn that sync push is destructive in dry-run output Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * docs(skills): clarify sync pull mutates local files, not read-only Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Co-authored-by: centdix <farhadg110@gmail.com>
68 lines
3.0 KiB
Markdown
68 lines
3.0 KiB
Markdown
# Windmill Triggers
|
|
|
|
Triggers allow external events to invoke your scripts and flows.
|
|
|
|
## File Naming
|
|
|
|
Trigger configuration files use the pattern: `{path}.{trigger_type}_trigger.yaml`
|
|
|
|
Examples:
|
|
- `u/user/webhook.http_trigger.yaml`
|
|
- `f/data/kafka_consumer.kafka_trigger.yaml`
|
|
- `f/sync/postgres_cdc.postgres_trigger.yaml`
|
|
- `f/inbound/orders.email_trigger.yaml`
|
|
|
|
## Email Triggers
|
|
|
|
An email trigger routes incoming emails to a script or flow. Each trigger reserves a local-part: emails sent to `<local_part>@<windmill_email_domain>` are delivered to the configured runnable. Set `workspaced_local_part: true` to namespace it per workspace (the actual recipient becomes `<workspace_id>-<local_part>@…`); on Windmill Cloud this is required.
|
|
|
|
Senders may append URL-style extras to the local-part with `+`: `mytrigger+foo=bar+baz=qux@…`. They flow through to the script as `email_extra_args` (see below).
|
|
|
|
### Payload
|
|
|
|
The runnable receives:
|
|
|
|
- `parsed_email` — `{ headers, text_body, html_body, attachments[] }`. Each `attachment` has `{ headers, body }`.
|
|
- `raw_email` — the raw RFC 822 message as a string, **or** an S3 object (`{ s3: "windmill_emails/<job_id>/raw.eml" }`) if the message exceeds 1 MiB.
|
|
- `email_extra_args` (optional, only when sender appended `+key=value` extras) — a flat object of the parsed extras.
|
|
|
|
With a preprocessor, all of the above are nested under `event` along with `event.kind = "email"` and `event.trigger_path` (the trigger's path). Without a preprocessor, `trigger_path` is **not** exposed — add a preprocessor if you need it.
|
|
|
|
### Attachments are S3 objects
|
|
|
|
Binary attachments are uploaded to the workspace S3 bucket and surface in `parsed_email.attachments[i].body` as:
|
|
|
|
```json
|
|
{ "s3": "windmill_emails/<job_id>/attachments/<filename>" }
|
|
```
|
|
|
|
To read the bytes inside a script, use the wmill SDK:
|
|
|
|
```ts
|
|
// TypeScript
|
|
import * as wmill from "windmill-client"
|
|
const file = await wmill.loadS3File(parsed_email.attachments[0].body)
|
|
```
|
|
|
|
```python
|
|
# Python
|
|
import wmill
|
|
data = wmill.load_s3_file(parsed_email["attachments"][0]["body"])
|
|
```
|
|
|
|
If the workspace has no S3 resource configured (Workspace Settings → Object storage), `body` falls back to the string `"configure s3 in the workspace settings to handle attachments"`. The same applies to large `raw_email` bodies. Email attachment storage requires the server to be built with the `parquet` feature.
|
|
|
|
Text/HTML/inline parts are placed inline in `body` as strings.
|
|
|
|
## CLI Commands
|
|
|
|
`wmill sync push` deploys local changes to the workspace and can be destructive to remote state — only suggest/run it when the user explicitly asks to deploy/publish/push, not when they say "run", "try", or "test". `sync pull` is safe to run yourself — it never mutates remote state, though it does overwrite local files to match the remote (use `sync pull --dry-run` to only preview).
|
|
|
|
```bash
|
|
# Push trigger configuration — only when the user explicitly asks to deploy
|
|
wmill sync push
|
|
|
|
# Pull triggers from Windmill
|
|
wmill sync pull
|
|
```
|