GitHub flows

Prerequisite: an active GitHub App installation

GitHub triggers and GitHub nodes both check your org's GitHub App status. If no active installation exists for github.com, the node shows "No active GitHub App installation" with an Install GitHub App link to Settings, Connected Apps. Nothing fires until the app is installed: deliveries have no credential to act under.

Once installed, the platform lists the repositories the installation can reach. Repository fields offer that list as autocomplete; typing a repo outside it shows "This repository is outside the current GitHub App scope" so you catch a bad target before the first run fails. If the repository list cannot load, the field falls back to manual owner/repository entry.

The GitHub trigger

1. 1Add a Trigger node and set its mode to Event.
2. 2Set the source to GitHub (the other option is Generic webhook).
3. 3Pick the repository and the event: New PR, CI failure, Vulnerability detected, or Push.
4. 4Set the per-event filters and save.

Filters depend on the event. New PR, CI failure, and Push take an optional branch filter (for example main or release/**; for New PR it matches the base branch). CI failure takes an optional exact workflow name: a repo with N workflows fires N deliveries per push, so naming one reduces fan-out. New PR has an "Include updates to open pull requests" checkbox.

The trigger node shows Recent deliveries inline: each delivery's event type, status, and any error message. A delivery that exhausted its attempts shows status dead with a Replay button, so a failed webhook is recoverable from the canvas without touching GitHub.

Generic event triggers

The Generic webhook source covers non-GitHub senders. Set an optional event name filter (the field hint reads "e.g. github.push - blank accepts any event"), then copy the Webhook URL and Signing secret from the node. Sign the raw JSON body with HMAC-SHA256 and send it as X-Armor-Signature: sha256=<hex>, with eventName and eventId in the body or as X-Armor-Event / X-Armor-Event-Id headers. The secret is hidden by default: Reveal shows it, Regenerate rotates it if it is ever exposed. Redeliveries with the same event id fire the flow at most once.

The GitHub node

The GitHub node performs write actions mid-flow. Pick one of four actions, each with its own parameters:

• →Comment: target a PR or an Issue by number, with a templated comment body.
• →Create branch: branch name plus an optional source ref (blank uses the default branch).
• →Commit files: branch, commit message, and up to 32 files, each with a path and content or a delete checkbox. "Create branch if missing" is on by default.
• →Open PR: head branch, optional base branch (blank uses the default branch), title, and optional body.

Every field accepts {{state...}} templates, including the repository itself, so a trigger payload can drive the target: for example {{state.trigger.payload.repo.fullName}} or a comment number of {{state.trigger.payload.pr.number}}. Each action publishes outputs to run state for downstream nodes: comment yields $output.commentId and $output.url, open PR yields $output.pr.number, $output.pr.url, $output.pr.head, and $output.pr.base.