Portal Community
Portal / Nodes / GitHub / Examples

Examples

Five GitHub webhook trigger examples: auto-deploy on push, PR review bot, auto-close stale issues, release notes workflow, and CI failure alert.

Example 1: Auto-Deploy on Push to Main

Trigger: push event to the main branch of the production repository. Start a deployment pipeline automatically when code lands on main.

Node settings:

AllowedEventTypes: push
AllowedRepositories: myorg/api-service
AllowedBranches: main
WebhookSecret: {{ secrets.github_webhook_secret }}
OnlyProcessNonEmptyPushes: true

Downstream workflow uses these output fields:

// Check forced push (should fail deployment)
{{ nodes.githubTrigger.output.forced_push }}

// Deploy commit SHA
{{ nodes.githubTrigger.output.after_commit }}

// Who pushed — for Slack notification
{{ nodes.githubTrigger.output.pusher }}

// Commit messages for changelog
{{ nodes.githubTrigger.output.commits[0].message }}

// Repository for environment lookup
{{ nodes.githubTrigger.output.repository }}

Workflow steps after trigger:

  1. IfCondition — if forced_push == true, route to alert channel and halt
  2. HTTP Request — trigger deployment pipeline API with after_commit
  3. Delay — wait for deployment to complete
  4. HTTP Request — check deployment health endpoint
  5. Slack — notify #deployments with commit summary and deployment URL
Expected outcome: Every merge to main triggers an automated deployment. Force pushes are caught before the pipeline starts. The team is notified in Slack with the commit author, message, and deployment result.

Example 2: PR Review Bot Trigger

Trigger: pull_request event with action "opened". When a new PR is opened, run automated checks and post a structured review comment.

Node settings:

AllowedEventTypes: pull_request
AllowedRepositories: myorg/api-service,myorg/web-app
AllowedPullRequestActions: opened
WebhookSecret: {{ secrets.github_webhook_secret }}

Downstream workflow uses these output fields:

// PR number for posting the comment back
{{ nodes.githubTrigger.output.pr_number }}

// Head branch — check naming convention
{{ nodes.githubTrigger.output.pr_head_branch }}

// Base branch — confirm merging to correct target
{{ nodes.githubTrigger.output.pr_base_branch }}

// PR title for quality check
{{ nodes.githubTrigger.output.pr_title }}

// Author for team lookup
{{ nodes.githubTrigger.output.sender_login }}

// Labels already applied
{{ nodes.githubTrigger.output.pr_labels }}

Workflow steps after trigger:

  1. IfCondition — check branch name follows feature/*, fix/*, or hotfix/* convention. If not, post a naming reminder comment.
  2. HTTP Request — look up code owners based on changed files (via GitHub API)
  3. HTTP Request (GitHub API) — post a review comment on the PR with the automated check results and assign appropriate code owners
  4. Slack — notify the relevant team channel that a review is needed, with a direct link to the PR
Expected outcome: Every new PR receives an automated comment within seconds of opening — checking naming conventions, assigning code owners, and alerting the team. Reviewers see everything they need without manual triage.

Example 3: Auto-Close Stale Issues

Trigger: issues event with action "labeled". When the "stale" label is applied to an issue (by a scheduled triage workflow), automatically add a closing comment and schedule the issue for closure.

Node settings:

AllowedEventTypes: issues
AllowedIssueActions: labeled
AllowedRepositories: myorg/api-service
WebhookSecret: {{ secrets.github_webhook_secret }}

Downstream workflow:

// Check if the applied label is "stale"
{{ nodes.githubTrigger.output.action }}        // "labeled"
{{ nodes.githubTrigger.output.issue_labels }}  // check array contains "stale"
{{ nodes.githubTrigger.output.issue_number }}  // for posting the comment
{{ nodes.githubTrigger.output.issue_title }}   // for notification
{{ nodes.githubTrigger.output.sender_login }}  // who labelled it

Workflow steps after trigger:

  1. IfCondition — confirm issue_labels includes "stale" (the label event may also fire for other labels)
  2. HTTP Request (GitHub API) — post a closing comment: "This issue has been automatically marked as stale due to inactivity. It will be closed in 7 days unless there is new activity."
  3. Delay — wait 7 days
  4. HTTP Request (GitHub API) — check if there has been any new activity on the issue since labelling
  5. IfCondition — if still stale, close the issue via GitHub API
  6. Slack — post a summary of closed stale issues to the engineering channel
Expected outcome: Stale issues are automatically triaged and closed on a 7-day grace period. The team is notified of closures without any manual issue management work.

Example 4: Release Notes Workflow

Trigger: release event with action "published". When a new release is published on GitHub, automatically generate formatted release notes and distribute them.

Node settings:

AllowedEventTypes: release
AllowedRepositories: myorg/api-service
WebhookSecret: {{ secrets.github_webhook_secret }}
IncludeFullEventObject: true

Output fields used downstream:

{{ nodes.githubTrigger.output.release_tag }}          // e.g. "v2.4.0"
{{ nodes.githubTrigger.output.release_name }}         // Display name
{{ nodes.githubTrigger.output.release_body }}         // Raw release notes
{{ nodes.githubTrigger.output.release_prerelease }}   // Skip Confluence post for pre-releases
{{ nodes.githubTrigger.output.release_url }}          // Link back to GitHub
{{ nodes.githubTrigger.output.release_published_at }} // Publication timestamp
{{ nodes.githubTrigger.output.sender_login }}         // Who published it

Workflow steps after trigger:

  1. IfCondition — if release_prerelease == true, only notify the beta channel; skip Confluence and full distribution
  2. AI Text Node — reformat release_body Markdown into a structured HTML changelog
  3. HTTP Request (Confluence API) — create or update the release notes page in Confluence
  4. Slack — post release announcement to #product-updates with tag, summary, and GitHub link
  5. Email (SMTP) — send release notes to the product stakeholder mailing list
Expected outcome: Within minutes of publishing a release on GitHub, formatted release notes appear in Confluence, Slack, and stakeholder inboxes — automatically. No manual writing or distribution needed.

Example 5: CI Failure Alert

Trigger: workflow_run event. When a GitHub Actions workflow completes with a failure conclusion, immediately alert the responsible team and create a tracking issue.

Node settings:

AllowedEventTypes: workflow_run
AllowedRepositories: myorg/api-service,myorg/web-app
WebhookSecret: {{ secrets.github_webhook_secret }}

Output fields used downstream:

{{ nodes.githubTrigger.output.workflow_status }}     // "completed"
{{ nodes.githubTrigger.output.workflow_conclusion }} // "failure", "timed_out", etc.
{{ nodes.githubTrigger.output.workflow_name }}       // Which workflow failed
{{ nodes.githubTrigger.output.workflow_branch }}     // Which branch
{{ nodes.githubTrigger.output.workflow_commit_sha }} // Failing commit
{{ nodes.githubTrigger.output.sender_login }}        // Who triggered the run
{{ nodes.githubTrigger.output.repository }}          // Which repo

Workflow steps after trigger:

  1. IfCondition — only proceed if workflow_status == "completed" AND workflow_conclusion == "failure" (or "timed_out")
  2. Slack — post to #ci-alerts: "CI FAILURE: {{ workflow_name }} on {{ repository }}@{{ workflow_branch }} — triggered by {{ sender_login }}. Commit: {{ workflow_commit_sha }}."
  3. HTTP Request (GitHub API) — create a GitHub issue in the repository with label "ci-failure" and assign to the on-call engineer
  4. IfCondition — if the failing branch is main, escalate: page on-call via PagerDuty and send a high-severity Slack alert
Expected outcome: CI failures on any branch generate an immediate Slack alert and a GitHub issue. Failures on main trigger an escalated page. Engineers have full context — repo, branch, commit, workflow name — without needing to check GitHub manually.