Automate with GitHub

Automate with GitHub lets you build rules that react to activity in your GitHub repositories and take action back on GitHub — no scripts required. It's for anyone managing infrastructure or incident workflows alongside a GitHub-based development team.

Overview

• Trigger automations from GitHub events like workflow runs, issues, pull requests, pushes, releases, and deployments
• Act on GitHub automatically — create issues, merge pull requests, trigger workflows, set commit status, and more
• Combine GitHub with the rest of InfraNest, such as opening a GitHub issue when an incident starts

Before you start

1. Go to Integrations and connect your GitHub account.
2. To use GitHub triggers (the When this happens side of a rule), you need the InfraNest Automations app installed — a token connection can only run GitHub actions, not trigger from GitHub events.
3. In the automation builder, GitHub triggers and actions appear together under the GitHub group.
4. If you choose a GitHub trigger before connecting, InfraNest will remind you to connect first.

React to GitHub activity (triggers)

1. Start a new automation and, under When this happens, choose a GitHub trigger — for example GitHub workflow run, GitHub issue, GitHub pull request, GitHub push, GitHub release, GitHub deployment, GitHub deployment status, GitHub commit status, or GitHub check run.
2. Add Only if filters to narrow things down — for example only the Branch, only a specific Repository, only failures, or only your Organization. The Repository and account fields suggest your connected repos and accounts as you type.
3. Keep a few filter quirks in mind:
   • GitHub push events include tags and deleted branches — filter on Branch and Deleted to react only to new commits.
   • GitHub comment (issue or PR) fires for both issues and pull requests — filter On a pull request to pick one.
   • GitHub release fires three times per release. Add Action equals published so your rule runs once — the builder will offer to add this for you.
   • Assignees (everyone on it) matches on every issue event; Assignee only matches the person just assigned or unassigned.
   • Production environment tells a production deploy apart from a preview one.
   • Attempt counts workflow re-runs — 1 is the first run.
   • Cooldown applies per issue, workflow, commit or deployment — a cooldown on one repository never blocks another.

Act on GitHub (actions)

1. Under Do this, select Add action and choose a GitHub action, such as Trigger GitHub workflow, Re-run GitHub workflow, Re-run failed jobs, Cancel GitHub run, Create GitHub issue, Comment on GitHub issue, Update GitHub issue, Close GitHub issue, Reopen GitHub issue, Add issue labels, Remove issue label, Assign GitHub issue, Merge pull request, Request PR review, Create GitHub deployment, Set deployment status, Create GitHub release, or Set commit status.
2. Choose which GitHub connection the action should run as. If you only have one, it's chosen automatically.
3. Fill in fields like Repository (owner/repo), Workflow file or id, Branch, Environment, Labels (comma-separated), Assignees (comma-separated) and Reviewers — these offer a searchable list from your connected GitHub, or you can type a value or insert a placeholder from the trigger.
4. If a list won't load, check the message under the field:
   • The connection needs to be connected again — reconnect it in Integrations.
   • The GitHub App is suspended — unsuspend it on GitHub under Settings → GitHub Apps → Configure.
   • It isn't allowed to read that list — grant the permission on GitHub.
   • It can't see that repository — add the repository to the app's access on GitHub, or use a token that can reach it.
   • GitHub couldn't be reached just now — try again shortly.

Start from a ready-made automation

1. Open GitHub under Integrations and look for Ready-made automations, or go to Automations and open Template library.
2. Select Use on a template, pick the repository or status page it should work with, and select Save automation.

Useful ready-made automations that connect GitHub to the rest of your setup:

• Incident opened → open a GitHub issue, paired with Incident resolved → close its GitHub issue, so issues track and close themselves automatically.
• Certificate expiring → open a GitHub issue, two weeks ahead.
• Domain expiring → open a GitHub issue, a month ahead.
• Release published → announce on status page, for full releases only (pre-releases are skipped).
• GitHub workflow failed → re-run failed jobs once — a flaky job gets one retry, then it's left for you.
• Deployment succeeded → check it is up → set commit status — InfraNest checks your environment right after GitHub reports the deployment and marks the commit accordingly. This check doesn't affect monitor uptime or open incidents.
• Deployment succeeded → purge the Cloudflare cache.
• Deployment succeeded → announce on status page.
• GitHub workflow failed → open an issue & alert, and Certificate expiring → run a GitHub workflow.

NoteThe three Deployment succeeded automations only act on production deploys, so preview deploys don't trigger announcements or cache purges.

Examples

1. SSL renewal failed → Create GitHub issue, add the infrastructure label, and set Assignees (comma-separated) to your DevOps team.
2. Incident resolved → Comment on GitHub issue, then Close GitHub issue — using Linked records to fill in the issue number and repository automatically. If no issue was opened for that incident, the step is skipped.
3. GitHub pull request merged into a branch → Run GitHub workflow, then Set deployment status.
4. A production health check passes → Set commit status to success.
5. GitHub release published → Post status-page announcement.

Good to know

• A GitHub trigger only fires once GitHub is connected and the app is subscribed to that event type. If a trigger never runs, ask your administrator to check the app's event subscriptions.
• Automations you run don't trigger your own GitHub triggers again — this stops a rule from reacting to its own comments or labels endlessly.
• If two InfraNest workspaces connect the same GitHub account, automations in both will react to its events.
• When one step creates something (like an issue or deployment), later steps in the same rule can reuse it automatically.
• Requesting a review from a team needs an organization connection, not a personal one.
• Some actions show a Pro badge and need a higher plan.

TipLeave the workflow branch field empty to use the repository's default branch — it doesn't have to be called main.

Troubleshooting

• Merge pull request only merges what the rule saw. If someone pushes new commits after the approval that started the rule, nothing is merged, and the run explains why.
• Retries: set Retry on transient failure to automatically retry a GitHub outage, timeout, or rate limit. A permanent refusal shows GitHub's own reason in Run history.
• If a later step points at an issue that was supposed to be created earlier (through Linked records) and none was created, that step is skipped rather than failed.