Triggers

Each repo in your config has a trigger_mode and optional poll_interval that control when deploys fire. Three modes are available.

Webhook mode

repos:
  - name: myapp
    url: git@github.com:yourorg/myapp.git
    trigger_mode: webhook

deeplo registers a webhook handler at /webhooks/github. When GitHub sends a push event for a tracked repo and branch, the daemon processes it immediately.

Only repos with trigger_mode: webhook or trigger_mode: hybrid dispatch deploys from webhook events. Repos configured as trigger_mode: poll ignore webhooks entirely.

Pros: instantaneous, no wasted polling

Cons: requires the daemon to be reachable from GitHub; missed webhooks are not retried

Configure by pointing GitHub to https://your-host:8080/webhooks/github. See Installation for setup steps.

Webhook signature validation requires DEEPLO_GITHUB_WEBHOOK_SECRET_FILE. Without it, any POST to /webhooks/github is accepted — fine for a local network, not for a public endpoint.

Poll mode

repos:
  - name: myapp
    url: git@github.com:yourorg/myapp.git
    trigger_mode: poll
    poll_interval: 60s   # default

deeplo runs git ls-remote against the repo URL on a fixed interval. If the branch tip SHA has changed since the last poll, a deploy is dispatched.

Repos configured as trigger_mode: poll are poll-only. Incoming webhooks for those repos are ignored.

Pros: works without inbound network access; no GitHub webhook setup required

Cons: introduces latency up to poll_interval; generates periodic git traffic

poll_interval accepts Go duration strings: 30s, 5m, 1h. Default is 60s.

Hybrid mode

repos:
  - name: myapp
    url: git@github.com:yourorg/myapp.git
    trigger_mode: hybrid
    poll_interval: 5m

Both webhook and polling are active. A push event fires immediately; polling fills in for missed webhooks (network outages, misconfigured secrets, etc.).

This is the recommended mode for production setups where you use GitHub webhooks. Set poll_interval longer than in pure poll mode — its role is safety-net, not primary trigger.

How deploys are deduplicated

deeplo does not deploy the same (project, host, commit SHA) twice once it has either:

• already recorded a running or successful deployment for that target SHA
• already dispatched that branch tip from the poller

That means:

1. If the same (project, host, SHA) is already running in deployment state, a new event for it is skipped.
2. If the same (project, host, SHA) already succeeded, a new event for it is skipped.
3. In poll mode, a branch tip SHA is dispatched once. A failed deploy for that same SHA is not retried automatically on the next poll cycle.
4. To retry after a failed deploy of the same SHA, trigger a new event intentionally, for example by pushing a new commit (or reverting and pushing).

How projects are selected from a repo event

When a new commit is detected on a repo:

1. The planner finds all projects whose repo field matches the repo name.
2. For each project, it checks whether any changed file matches the project's watch_paths glob patterns.
3. Projects with no matching changed files are skipped.
4. Projects with empty watch_paths always deploy (every push triggers them).

If the commit diff is unavailable, all matching projects deploy unconditionally. This happens on the first seen commit for a repo/branch and in poll mode when no local diff baseline is available yet.

See Configuration for watch_paths glob syntax.