diff --git a/ai/authoring-prompt.mdx b/ai/authoring-prompt.mdx index 32a182a..4d78dad 100644 --- a/ai/authoring-prompt.mdx +++ b/ai/authoring-prompt.mdx @@ -20,7 +20,7 @@ Trigger { source, event, filter?, with? }. For integrations, source is the CONNECTION SLUG (e.g. github_, sentry_, or your webhook slug), not the bare provider name; for on-demand runs it is literally "manual". Shipped events: manual/fire, github push (+ other GitHub events), sentry issue.(created|resolved| -assigned|archived|unresolved), custom-webhook/webhook.received. At most one manual +assigned|archived|unresolved), custom-webhook/received. At most one manual trigger. Job { steps (>=1), needs?, runner?, env? }. Jobs run in parallel; each is isolated @@ -62,7 +62,7 @@ evaluated yet. event.ref on a push is the full Git ref (e.g. "refs/heads/main"). The prompt is deliberately compact but complete. It covers every dimension of the shipped schema: - **Top-level schema fields** — `name`, `runner`, `env`, `triggers`, `jobs`, and which keys are rejected -- **Trigger sources (shipped today)** — `manual`, plus integration connection slugs for GitHub (`push`), Sentry (`issue.*`), and custom webhooks (`webhook.received`) +- **Trigger sources (shipped today)** — `manual`, plus integration connection slugs for GitHub (`push`), Sentry (`issue.*`), and custom webhooks (`received`) - **Job isolation and `needs` ordering** — parallel execution, repo re-cloning, and dependency chaining - **Step kinds: run vs. agent** — the two mutually exclusive step shapes and their allowed fields - **Gate / restart_from rules** — CEL expressions over `exit_code` and how to wire restart targets diff --git a/concepts/runner-provisioners.mdx b/concepts/runner-provisioners.mdx index c4021a3..7fbecc7 100644 --- a/concepts/runner-provisioners.mdx +++ b/concepts/runner-provisioners.mdx @@ -78,6 +78,10 @@ configured through environment variables: | `SHIPFOX_PROVISIONER_DOCKER_NETWORK` | no | Docker network to attach runners to | | `SHIPFOX_PROVISIONER_DOCKER_EXTRA_HOSTS` | no | Extra host mappings (e.g. `host.docker.internal:host-gateway`) | +Create the provisioner token (`SHIPFOX_PROVISIONER_TOKEN`) on **Settings → Runner +Provisioners** in the dashboard — the value is shown once, and you can revoke it +there. + Poll intervals, reservation limits, token batch size, and the registration deadline have sensible defaults and can be tuned with additional `SHIPFOX_PROVISIONER_*` variables. diff --git a/concepts/triggers.mdx b/concepts/triggers.mdx index 72db657..2201ce1 100644 --- a/concepts/triggers.mdx +++ b/concepts/triggers.mdx @@ -33,7 +33,7 @@ triggers: The specific event from that source (for example `push`, `issue.created`, - `webhook.received`, or `fire`). Must be at least one character. Each integration + `received`, or `fire`). Must be at least one character. Each integration page lists the events it emits. diff --git a/integrations/linear.mdx b/integrations/linear.mdx index 94e06c2..b098e49 100644 --- a/integrations/linear.mdx +++ b/integrations/linear.mdx @@ -23,7 +23,7 @@ integration emits. Linear can already reach Shipfox through a [custom webhook](/integrations/webhooks): create a webhook connection, point a Linear webhook at its ingest URL, and trigger -on `webhook.received` — the run gets Linear's payload as its `event` context. +on `received` — the run gets Linear's payload as its `event` context. ## Related pages diff --git a/integrations/overview.mdx b/integrations/overview.mdx index e0c7309..3a6a425 100644 --- a/integrations/overview.mdx +++ b/integrations/overview.mdx @@ -40,7 +40,7 @@ and target each independently from different workflows. |---|---|---| | [GitHub](/integrations/github) | ✅ Shipped | `push` and other repository events | | [Sentry](/integrations/sentry) | ✅ Shipped | `issue.created`, `issue.resolved`, `issue.assigned`, `issue.archived`, `issue.unresolved` | -| [Custom webhook](/integrations/webhooks) | ✅ Shipped | `webhook.received` | +| [Custom webhook](/integrations/webhooks) | ✅ Shipped | `received` | | [Linear](/integrations/linear) | 🚧 Coming soon | — | | [Slack](/integrations/slack) | 🚧 Coming soon | — | | GitLab | 🔜 Roadmap | — | diff --git a/integrations/slack.mdx b/integrations/slack.mdx index 1f19cc8..3ec6400 100644 --- a/integrations/slack.mdx +++ b/integrations/slack.mdx @@ -23,7 +23,7 @@ integration emits. Slack can already reach Shipfox through a [custom webhook](/integrations/webhooks): create a webhook connection and point a Slack outgoing webhook or automation at its -ingest URL, then trigger on `webhook.received`. For the other direction, a `run` +ingest URL, then trigger on `received`. For the other direction, a `run` step can post to a Slack incoming webhook today (`curl` to your Slack webhook URL). ## Related pages diff --git a/integrations/webhooks.mdx b/integrations/webhooks.mdx index f1899f2..c54de4b 100644 --- a/integrations/webhooks.mdx +++ b/integrations/webhooks.mdx @@ -1,11 +1,11 @@ --- title: "Custom Webhooks: Trigger Workflows from Any System" sidebarTitle: "Custom webhook" -description: "Create a Shipfox webhook connection, point any system at its URL, and trigger workflows on the webhook.received event. The connection slug is your trigger source." +description: "Create a Shipfox webhook connection, point any system at its URL, and trigger workflows on the received event. The connection slug is your trigger source." --- A **custom webhook** connection gives you a unique URL that any system can POST to. -Every request that arrives fires the `webhook.received` event, which your workflows +Every request that arrives fires the `received` event, which your workflows can trigger on. Use it for tools Shipfox doesn't integrate with directly — CI systems, monitoring, internal services, or anything that can send an HTTP request. @@ -32,7 +32,7 @@ systems, monitoring, internal services, or anything that can send an HTTP reques Shipfox responds `202 Accepted` with a `delivery_id`. - Author a trigger using the connection slug as `source` and `webhook.received` + Author a trigger using the connection slug as `source` and `received` as `event`. @@ -43,10 +43,10 @@ systems, monitoring, internal services, or anything that can send an HTTP reques triggers: on_webhook: source: deploy_hook # your webhook connection slug - event: webhook.received + event: received ``` -`webhook.received` is the only event a custom webhook emits — every request to the +`received` is the only event a custom webhook emits — every request to the ingest URL fires it. ## Event payload diff --git a/reference/trigger-sources.mdx b/reference/trigger-sources.mdx index 76ee66c..cd5a90d 100644 --- a/reference/trigger-sources.mdx +++ b/reference/trigger-sources.mdx @@ -17,7 +17,7 @@ integration page. | Manual | `manual` (literal) | `fire` | None — [Triggers](/concepts/triggers#manual-trigger) | | GitHub | connection slug, e.g. `github_acme` | `push` and other repository events | [GitHub](/integrations/github) | | Sentry | connection slug, e.g. `sentry_acme` | `issue.created`, `issue.resolved`, `issue.assigned`, `issue.archived`, `issue.unresolved` | [Sentry](/integrations/sentry) | -| Custom webhook | connection slug you choose | `webhook.received` | [Custom webhook](/integrations/webhooks) | +| Custom webhook | connection slug you choose | `received` | [Custom webhook](/integrations/webhooks) | | Cron | 🚧 Coming soon — `cron` (literal) | `tick` | [Triggers](/concepts/triggers#coming-soon) | | Linear | 🚧 Coming soon | — | [Linear](/integrations/linear) | | Slack | 🚧 Coming soon | — | [Slack](/integrations/slack) |