GITHUB n8n INTEGRATION: AUTOMATE GITHUB WITH N8N

This action retrieves all GitHub Actions workflows configured in a specific repository. It's your starting point for any workflow automation—giving you visibility into what CI/CD processes exist before triggering or managing them programmatically.

Key parameters: Credential to connect with (required dropdown for GitHub account authentication), Resource (preset to "Workflow"), Operation (set to "List"), Repository Owner (required dropdown to select user or organization), Repository Name (required dropdown to choose the specific repository).

Typical use cases: Audit all workflows in a repository before implementing automation, build dynamic interfaces that let users select which workflow to trigger, create inventory reports of CI/CD configurations across multiple repositories, validate workflow existence before attempting dispatch operations.

When to use it: Perfect for discovery phases when building workflow management dashboards or before implementing dispatch automations where you need to know what's available.

This action fetches usage metrics for a specific GitHub Actions workflow, giving you insights into how much compute time and resources your CI/CD processes consume. Essential for cost monitoring and optimization in organizations with significant GitHub Actions usage.

Key parameters: Credential to connect with (required), Resource (set to "Workflow"), Operation (configured to "Get Usage"), Repository Owner (required dropdown), Repository Name (required dropdown), Workflow (required dropdown to select specific workflow to analyze).

Typical use cases: Build automated reports tracking workflow costs across repositories, alert finance teams when workflow usage approaches budget thresholds, compare usage patterns between different workflows to identify optimization opportunities, feed data into BI dashboards for engineering efficiency metrics.

When to use it: Ideal for DevOps teams managing costs or engineering managers needing visibility into CI/CD resource consumption.

Retrieve detailed information about a specific GitHub Actions workflow, including its configuration, state, and metadata. This action provides everything you need to understand a workflow's setup before interacting with it.

Key parameters: Credential to connect with (required), Resource (preset to "Workflow"), Operation (set to "Get"), Repository Owner (required dropdown), Repository Name (required dropdown), Workflow (required dropdown to choose specific workflow).

Typical use cases: Verify workflow configuration before triggering dispatch, check if a workflow is enabled/disabled programmatically, extract workflow metadata for documentation generation, validate workflow existence in conditional automation logic.

When to use it: Use this when you need detailed workflow information before taking action, or when building conditional logic based on workflow state.

Programmatically enable a GitHub Actions workflow that has been previously disabled. This action is crucial for managing workflow availability across repositories without manual intervention.

Key parameters: Credential to connect with (required), Resource (set to "Workflow"), Operation (configured to "Enable"), Repository Owner (required dropdown), Repository Name (required dropdown), Workflow (required dropdown).

Typical use cases: Automatically enable workflows during business hours and disable them after, re-enable workflows after scheduled maintenance windows, create admin interfaces for workflow management across multiple repos, implement approval-based workflow activation systems.

When to use it: Perfect for scheduled workflow management or building administrative tools for repository governance.

This powerful action triggers a GitHub Actions workflow and waits for it to complete before continuing your n8n workflow. It generates a resumeUrl that the GitHub workflow can call back, creating true synchronous automation between n8n and GitHub Actions.

Key parameters: Credential to connect with (required), Resource (set to "Workflow"), Operation ("Dispatch and Wait for Completion"), Repository Owner (required), Repository Name (required), Workflow (required), Ref (required Git reference), Inputs (optional JSON object for workflow parameters).

Typical use cases: Trigger deployment workflows and wait for confirmation before notifying stakeholders, run test suites and process results in subsequent n8n nodes, execute build workflows and proceed with release creation upon success, chain multiple repository workflows in sequence with guaranteed completion.

When to use it: Essential when your automation depends on workflow completion status—deployments, tests, builds, or any process where you need to know the outcome.

💡 TIP: The dispatched workflow must call back to the resumeUrl to complete the waiting. Configure your GitHub workflow to include a step that posts to this URL when finished.

Trigger a GitHub Actions workflow without waiting for completion. This fire-and-forget approach is ideal when you need to start workflows but don't need to track their outcome in the same automation.

Key parameters: Credential to connect with (required), Resource (set to "Workflow"), Operation ("Dispatch"), Repository Owner (required), Repository Name (required), Workflow (required), Ref (required Git reference), Inputs (optional JSON object).

Typical use cases: Kick off nightly builds from scheduled n8n workflows, trigger deployments from external events (form submissions, webhooks), start long-running workflows where completion tracking isn't needed, implement event-driven CI/CD from non-GitHub sources.

When to use it: Use this when you need to trigger workflows quickly without blocking your n8n workflow for completion.

Programmatically disable a GitHub Actions workflow, preventing it from running until re-enabled. Essential for maintenance periods, cost control, or conditional workflow availability.

Key parameters: Credential to connect with (required), Resource (set to "Workflow"), Operation ("Disable"), Repository Owner (required), Repository Name (required), Workflow (required).

Typical use cases: Disable expensive workflows during low-budget periods, implement scheduled workflow availability windows, emergency workflow shutdown during incidents, cost optimization by disabling unused workflows.

Send an invitation to add a user to a GitHub organization. This action streamlines onboarding processes by automating the tedious task of manually inviting new team members.

Key parameters: Credential to connect with (required GitHub account with organization admin permissions), Resource (set to "User"), Operation ("Invite"), Organization (required text input for organization name), Email (required email address of person to invite).

Typical use cases: Automate developer onboarding from HR systems, create self-service organization access requests, batch invite contractors when projects start, sync organization membership with identity providers.

Retrieve all issues associated with the authenticated user across all repositories. This provides a consolidated view of issues assigned to or created by a specific user.

Key parameters: Credential to connect with (required), Resource (set to "User"), Operation ("Get Issues"), Return All (toggle to fetch all issues or limit results), Limit (maximum issues to return when not returning all, default: 50), Filters (optional filtering criteria).

Typical use cases: Build personal productivity dashboards showing current assignments, generate weekly reports of user activity across repositories, track workload distribution across team members, create alerts when users have too many open issues.

Fetch repositories accessible to a specific user, providing visibility into available repositories for subsequent operations.

Key parameters: Credential to connect with (required), Resource (set to "User"), Operation ("Get Repositories"), Repository Owner (required dropdown to select user), Return All (toggle for complete or limited results), Limit (maximum repositories, default: 50).

Typical use cases: Build repository selection interfaces for user workflows, audit repository access across organization members, generate repository inventories for compliance reporting, create onboarding documentation showing available repos.

Modify an existing pull request review, allowing you to update review comments or change review status programmatically.

Key parameters: Credential to connect with (required), Resource (set to "Review"), Operation ("Update"), Repository Owner (required), Repository Name (required), PR Number (required pull request number), Review ID (required unique identifier), Body (new content for review text).

Typical use cases: Programmatically update review comments based on automated checks, modify reviews when CI results change, implement review management workflows with approval escalation.

Retrieve multiple reviews from a specific pull request, providing comprehensive visibility into the review status and feedback on code changes.

Key parameters: Credential to connect with (required), Resource (set to "Review"), Operation ("Get Many"), Repository Owner (required), Repository Name (required), PR Number (required), Return All (toggle), Limit (maximum reviews, default: 50).

Typical use cases: Build PR status dashboards showing review progress, generate metrics on review turnaround times, alert when PRs lack sufficient reviews, create review summary reports for team meetings.

Fetch detailed information about a specific pull request review, including the reviewer's comments, state, and submission time.

Key parameters: Credential to connect with (required), Resource (set to "Review"), Operation ("Get"), Repository Owner (required), Repository Name (required), PR Number (required), Review ID (required specific review identifier).

Typical use cases: Retrieve review details for notification systems, build audit trails of review activity, extract review comments for documentation.

Submit a new review on a pull request, allowing automated approval, change requests, or comments based on external criteria.

Key parameters: Credential to connect with (required), Resource (set to "Review"), Operation ("Create"), Repository Owner (required), Repository Name (required), PR Number (required), Event (required review type—"Approve", "Request Changes", or "Comment"), Additional Fields (optional extra properties).

Typical use cases: Auto-approve PRs that pass all automated checks, request changes when security scans detect issues, add automated comments summarizing test results, implement bot-based code review assistance.

💡 TIP: Be thoughtful about auto-approval workflows. Consider requiring human review for critical paths while automating routine approvals.

Retrieve traffic referrer data for a repository, showing which external sites are driving visitors to your repository.

Key parameters: Credential to connect with (required), Resource (set to "Repository"), Operation ("List Referrers"), Repository Owner (required), Repository Name (required).

Typical use cases: Build marketing dashboards tracking repository traffic sources, identify which blog posts or docs drive the most repository visits, monitor referral trends over time, generate weekly traffic reports for stakeholders.

Fetch data about the most-visited paths within a repository, revealing which files and directories attract the most attention.

Key parameters: Credential to connect with (required), Resource (set to "Repository"), Operation ("List Popular Paths"), Repository Owner (required), Repository Name (required).

Typical use cases: Identify which documentation files need the most attention, understand user navigation patterns in your codebase, prioritize improvements based on visitor behavior, track impact of documentation changes.

Retrieve pull requests from a repository with optional filtering, essential for building PR management and monitoring workflows.

Key parameters: Credential to connect with (required), Resource (set to "Repository"), Operation ("Get Pull Requests"), Repository Owner (required), Repository Name (required), Return All (toggle), Limit (maximum PRs, default: 50), Filters (optional criteria).

Typical use cases: Build PR dashboards showing current open requests, alert on stale PRs needing attention, generate weekly PR activity reports, track PR velocity metrics over time.

Retrieve the community profile metrics for a repository, including README presence, license, and contributing guidelines.

Key parameters: Credential to connect with (required), Resource (set to "Repository"), Operation ("Get Profile"), Repository Owner (required), Repository Name (required).

Typical use cases: Audit repositories for community health standards, generate compliance reports on documentation presence, identify repos missing key community files, track profile improvements over time.

Fetch license information for a repository, including the license type and its terms.

Key parameters: Credential to connect with (required), Resource (set to "Repository"), Operation ("Get License"), Repository Owner (required), Repository Name (required).

Typical use cases: Audit license compliance across organization repositories, generate reports on license distribution, alert on repositories missing licenses, validate license compatibility for dependencies.

Retrieve issues from a specific repository with optional filtering by state, labels, and other criteria.

Key parameters: Credential to connect with (required), Resource (set to "Repository"), Operation ("Get Issues"), Repository Owner (required), Repository Name (required), Return All (toggle), Limit (maximum issues, default: 50), Filters (optional criteria).

Typical use cases: Build issue tracking dashboards, generate bug reports for stakeholder meetings, monitor issue volume trends, create alerts for high-priority issues.

Fetch detailed information about a specific repository, including statistics, settings, and metadata.

Key parameters: Credential to connect with (required), Resource (set to "Repository"), Operation ("Get"), Repository Owner (required), Repository Name (required).

Typical use cases: Retrieve repository metadata for documentation, check repository settings programmatically, build repository information dashboards, validate repository existence before operations.

Modify an existing release, allowing updates to release notes, names, or other metadata after publication.

Key parameters: Credential to connect with (required), Resource (set to "Release"), Operation ("Update"), Repository Owner (required), Repository Name (required), Release ID (required identifier to update), Additional Fields (optional properties to modify).

Typical use cases: Update release notes with additional changelog entries, modify release names after version adjustments, add download statistics or links post-publication.

Retrieve multiple releases from a repository, providing visibility into release history and versioning.

Key parameters: Credential to connect with (required), Resource (set to "Release"), Operation ("Get Many"), Repository Owner (required), Repository Name (required), Return All (toggle), Limit (maximum releases, default: 50).

Typical use cases: Build release history dashboards, generate changelogs from release notes, track release cadence metrics, compare release patterns across repositories.

Fetch detailed information about a specific release, including assets, notes, and metadata.

Key parameters: Credential to connect with (required), Resource (set to "Release"), Operation ("Get"), Repository Owner (required), Repository Name (required), Release ID (required identifier of target release).

Typical use cases: Retrieve release notes for notification systems, extract release metadata for documentation, validate release existence before linking.

Remove a release from a repository, useful for cleanup or removing erroneous publications.

Key parameters: Credential to connect with (required), Resource (set to "Release"), Operation ("Delete"), Repository Owner (required), Repository Name (required), Release ID (required identifier of release to remove).

Typical use cases: Clean up test or draft releases, remove accidental publications, implement release governance workflows.

Publish a new release for a repository, automating the release process with customizable notes and settings.

Key parameters: Credential to connect with (required), Resource (set to "Release"), Operation ("Create"), Repository Owner (required), Repository Name (required), Tag (required Git tag for the release), Additional Fields (optional properties like name, body, draft status, prerelease flag).

Typical use cases: Automate release creation from CI/CD pipelines, create releases when milestone conditions are met, generate releases with automated changelog compilation, implement version bump workflows.

Fetch all repositories belonging to a GitHub organization, essential for organization-wide auditing and management.

Key parameters: Credential to connect with (required), Resource (set to "Organization"), Operation ("Get Repositories"), Repository Owner (required dropdown to select organization), Return All (toggle), Limit (maximum repositories, default: 50).

Typical use cases: Audit all organization repositories, build repository catalogs for internal documentation, track repository growth over time, generate compliance reports.

Lock an issue to prevent further comments, useful for resolved or contentious discussions.

Key parameters: Credential to connect with (required), Resource (set to "Issue"), Operation ("Lock"), Repository Owner (required), Repository Name (required), Issue Number (required issue to lock), Lock Reason (optional reason—"Resolved", "Off-topic", "Spam", or "Too heated").

Typical use cases: Automatically lock resolved issues after a grace period, lock spam or abusive issues when detected, implement moderation workflows for community repos.

Retrieve detailed information about a specific issue, including comments, labels, and assignees.

Key parameters: Credential to connect with (required), Resource (set to "Issue"), Operation ("Get"), Repository Owner (required), Repository Name (required), Issue Number (required target issue number).

Typical use cases: Fetch issue details for notification systems, extract issue data for reporting, build issue detail views in custom interfaces.

Modify an existing issue's properties, including title, body, labels, assignees, and state.

Key parameters: Credential to connect with (required), Resource (set to "Issue"), Operation ("Edit"), Repository Owner (required), Repository Name (required), Issue Number (required issue to modify), Edit Fields (properties to update—title, body, state, labels, assignees, etc.).

Typical use cases: Auto-label issues based on content analysis, assign issues to team members from external triggers, update issue status from project management tools, add labels when specific conditions are met.

Add a comment to an existing issue, enabling automated responses and updates.

Key parameters: Credential to connect with (required), Resource (set to "Issue"), Operation ("Create Comment"), Repository Owner (required), Repository Name (required), Issue Number (required target issue), Body (required comment content).

Typical use cases: Post automated status updates on issues, add bot responses to common questions, comment with CI/CD results or test outcomes, acknowledge issue creation with welcome messages.

Create a new issue in a repository, automating issue creation from external sources.

Key parameters: Credential to connect with (required), Resource (set to "Issue"), Operation ("Create"), Repository Owner (required), Repository Name (required), Title (required issue title), Body (optional but recommended issue description), Labels (optional tags for categorization), Assignees (optional users to assign).

Typical use cases: Create issues from customer support tickets, generate bug reports from monitoring alerts, convert form submissions into issues, sync issues from external project management tools.

💡 TIP: Include structured information in issue bodies using Markdown. Templates make issues more actionable and easier to triage.

List files in a specific directory within a repository, useful for discovering content structure.

Key parameters: Credential to connect with (required), Resource (set to "File"), Operation ("List"), Repository Owner (required), Repository Name (required), Path (optional directory path to list, e.g., "docs/", defaults to root).

Typical use cases: Build file browsers for repository content, audit documentation structure, generate directory listings for navigation, discover available files before operations.

Retrieve the contents of a specific file from a repository, enabling file-based automation.

Key parameters: Credential to connect with (required), Resource (set to "File"), Operation ("Get"), Repository Owner (required), Repository Name (required), File Path (required path to target file, e.g., "docs/README.md"), As Binary Property (toggle for binary file handling), Put Output File in Field (name for output binary field), Additional Parameters (optional extra settings).

Typical use cases: Fetch configuration files for processing, retrieve documentation for publishing, extract data files for analysis, sync repository content to other systems.

Update an existing file in a repository with new content, creating a commit in the process.

Key parameters: Credential to connect with (required), Resource (set to "File"), Operation ("Edit"), Repository Owner (required), Repository Name (required), File Path (required path to file to edit), Binary File (toggle for binary content), File Content (required new content for text files), Commit Message (required description of change), Additional Parameters (optional settings like branch specification).

Typical use cases: Update configuration files from external systems, sync documentation with content management tools, automate changelog updates, push generated content to repositories.

Remove a file from a repository, creating a commit that records the deletion.

Key parameters: Credential to connect with (required), Resource (set to "File"), Operation ("Delete"), Repository Owner (required), Repository Name (required), File Path (required path to file to remove), Commit Message (optional description of deletion), Additional Parameters (optional extra settings).

Typical use cases: Clean up deprecated documentation, remove temporary files automatically, implement file lifecycle management.

Add a new file to a repository, creating a commit with the new content.

Key parameters: Credential to connect with (required), Resource (set to "File"), Operation ("Create"), Repository Owner (required), Repository Name (required), File Path (required path and name for new file), Binary File (toggle for binary content), File Content (required content for text files), Commit Message (required description of addition), Additional Parameters (optional settings like branch specification).

Typical use cases: Generate documentation from templates, create configuration files for new projects, add generated reports to repositories, push content from external sources to GitHub.