نود Github در N8N

نود Github در N8N

نود GitHub در n8n یک پل آماده بین ورکفلوهای اتوماسیون و سرویس GitHub است؛ با آن می‌توانید کارهایی مثل ساخت Issue، ایجاد Pull Request، مدیریت فایل‌ها و ریلیزها، و واکنش به رویدادهای مخزن را بدون نوشتن کد انجام دهید. نتیجه، اتوماسیونی است که تیم‌های توسعه، DevOps و حتی تیم‌های محصول می‌توانند برای کاهش کارهای تکراری و افزایش سرعت تحویل استفاده کنند.

معرفی نود در N8N

نود GitHub به شما اجازه می‌دهد با GitHub API تعامل کنید: اطلاعات مخزن را بخوانید، منابع جدید بسازید یا به‌روزرسانی کنید، و در برخی حالت‌ها با دریافت رویدادها، ورکفلو را به‌صورت خودکار اجرا کنید.

  • کارکرد کلی: اتصال به GitHub و انجام عملیات روی Repositoryها، Issueها، Pull Requestها، فایل‌ها، کامنت‌ها، ریلیزها و…
  • دسته‌بندی: Integration (و بسته به نسخه/ساختار ورکفلو، می‌تواند در نقش Action هم استفاده شود). برای رویدادها معمولاً از GitHub Trigger استفاده می‌شود.
  • اهمیت در ورکفلوها: اتوماسیون چرخه توسعه نرم‌افزار (SDLC)، هماهنگی تیمی، تریاژ باگ‌ها، گزارش‌گیری، همگام‌سازی با Slack/Email/Jira/Notion و حتی عملیات DevOps.

موارد استفاده

۱) تریاژ خودکار Issueها

  • با دریافت یک Issue جدید (از GitHub Trigger)، بر اساس متن/برچسب‌ها/کلمات کلیدی، به‌صورت خودکار Label اضافه کنید، Assignee تعیین کنید، و پیام اطلاع‌رسانی به Slack بفرستید.
  • ترکیب پیشنهادی: GitHub Trigger → IF → GitHub (Add Labels / Assign) → Slack

۲) ساخت Release Note از Pull Requestها

  • در زمان انتشار نسخه جدید، لیست PRهای Merge شده را جمع‌آوری کنید، متن Release Note بسازید، و یک Release در GitHub ایجاد کنید.
  • ترکیب پیشنهادی: Cron → GitHub (List Pull Requests / Compare Commits) → Function / Code → GitHub (Create Release)

۳) سینک فایل‌ها و کانفیگ‌ها در مخزن

  • تولید خودکار فایل (مثلاً changelog، لیست مشتریان، یا خروجی گزارش) و Commit کردن آن در Repository.
  • ترکیب پیشنهادی: HTTP Request / Database → Function / Code → GitHub (Create/Update File) → GitHub (Create Commit اگر لازم باشد)

۴) ساخت Issue از فرم‌های وب یا تیکت‌های پشتیبانی

  • با دریافت پیام از فرم سایت، ایمیل یا سیستم تیکتینگ، یک Issue با قالب استاندارد بسازید و به تیم مربوطه assign کنید.
  • ترکیب پیشنهادی: Webhook / IMAP Email → Set → GitHub (Create Issue) → Slack/Email

۵) کنترل کیفیت و اتوماسیون Code Review

  • پس از ایجاد PR، چک‌لیست قوانین (وجود توضیح کافی، لینک تیکت، تست‌ها) را بررسی کنید و کامنت خودکار ثبت کنید.
  • ترکیب پیشنهادی: GitHub Trigger (PR opened) → Function / Code → GitHub (Create Review Comment / Create Issue Comment)

پارامترها و تنظیمات

پارامترها در n8n ممکن است بسته به نسخه، کمی جابه‌جا یا با نام‌های نزدیک نمایش داده شوند، اما منطق کلی ثابت است: ابتدا Credential را تنظیم می‌کنید، سپس Resource و Operation را انتخاب می‌کنید، و در نهایت فیلدهای مخصوص همان عملیات را پر می‌کنید.

۱) Credentials (احراز هویت)

  • نام پارامتر: Credentials (GitHub API)

    نوع داده: انتخاب Credential

    توضیح: معمولاً با Personal Access Token (Classic یا Fine-grained) یا OAuth انجام می‌شود.

    مثال عملی: ساخت PAT با دسترسی به repo و workflow برای خواندن/نوشتن Issue و PR.

نکته مهم: اگر روی Repoهای خصوصی کار می‌کنید، Token باید دسترسی مناسب داشته باشد. برای Fine-grained token لازم است Repository access و Permissions (Issues/Pull requests/Contents و…) درست تنظیم شوند.

۲) Resource (منبع)

  • نام پارامتر: Resource

    نوع داده: گزینه‌ای (Select)

    توضیح: مشخص می‌کند با کدام بخش GitHub کار دارید (Issue، Pull Request، Repository، Release، File/Content، User و…)

    مثال عملی: انتخاب Resource = Issue برای ساخت یا لیست کردن Issueها.

۳) Operation (عملیات)

  • نام پارامتر: Operation

    نوع داده: گزینه‌ای (Select)

    توضیح: روی منبع انتخابی چه کاری انجام شود (Create, Get, Get Many/List, Update, Delete و…)

    مثال عملی: Resource = Issue و Operation = Create برای ساخت Issue جدید.

۴) Owner و Repository

  • نام پارامتر: Owner

    نوع داده: رشته (String)

    توضیح: نام سازمان (org) یا یوزر مالک مخزن.

    مثال: n8n-io

  • نام پارامتر: Repository

    نوع داده: رشته (String)

    توضیح: نام مخزن بدون owner.

    مثال: n8n

نکته مهم: در بسیاری از عملیات‌ها، Owner/Repo اجباری است و باید دقیق مطابق نام مخزن باشد (حساس به خطاهای تایپی).

۵) پارامترهای متداول برای Issue (نمونه‌های پرکاربرد)

  • Title | نوع: String | کاربرد: عنوان Issue | مثال: Bug: Login button not working
  • Body | نوع: String | کاربرد: متن Issue (Markdown) | مثال: Steps to reproduce…
  • Labels | نوع: Array/String | کاربرد: برچسب‌ها | مثال: [“bug”,”high-priority”]
  • Assignees | نوع: Array | کاربرد: انتساب به کاربران | مثال: [“ali-dev”,”sara-qc”]
  • Milestone | نوع: Number/String (ID) | کاربرد: اتصال Issue به مایلستون | مثال: 12
  • State | نوع: Select (open/closed) | کاربرد: بستن یا بازکردن Issue | مثال: closed

۶) پارامترهای متداول برای Pull Request

  • Title | نوع: String | کاربرد: عنوان PR | مثال: Add caching layer for API
  • Body | نوع: String | کاربرد: توضیحات PR | مثال: This PR adds…
  • Head | نوع: String | کاربرد: شاخه مبدا | مثال: feature/cache
  • Base | نوع: String | کاربرد: شاخه مقصد | مثال: main
  • Draft | نوع: Boolean | کاربرد: ایجاد PR به صورت Draft | مثال: true

۷) پارامترهای متداول برای File/Contents (ایجاد یا به‌روزرسانی فایل)

  • File Path | نوع: String | کاربرد: مسیر فایل داخل Repo | مثال: reports/daily.json
  • Content | نوع: String (معمولاً base64 یا متن) | کاربرد: محتوای فایل | مثال: {“date”:”2026-02-13″,”count”:120}
  • Message | نوع: String | کاربرد: پیام Commit | مثال: chore: update daily report
  • Branch | نوع: String | کاربرد: شاخه هدف | مثال: main
  • SHA | نوع: String | کاربرد: برای Update فایل موجود لازم است (SHA نسخه فعلی فایل) | مثال: 3d21ec53a331a6f…

نکته مهم: برای آپدیت فایل، معمولاً باید ابتدا فایل را Get کنید تا SHA آن را داشته باشید، سپس Update را انجام دهید؛ در غیر این صورت خطای 409 یا 422 محتمل است.

۸) Options و Additional Fields (گزینه‌های تکمیلی)

  • Pagination / Limit | نوع: Number | کاربرد: محدودکردن تعداد آیتم‌های دریافتی در عملیات‌های لیستی | مثال: 50
  • Return All | نوع: Boolean | کاربرد: دریافت همه نتایج (ممکن است کندتر شود) | مثال: false
  • Filters | نوع: Object/Fields | کاربرد: فیلتر براساس state، label، sort و… | مثال: state=open

ورودی‌ها و خروجی‌ها

ورودی (Input)

نود GitHub معمولاً ورودی را به شکل آیتم‌های n8n دریافت می‌کند (هر آیتم یک JSON). شما می‌توانید فیلدهای Owner/Repo/Title و… را ثابت وارد کنید یا با Expression از ورودی بخوانید.

نمونه ورودی برای ساخت Issue (یک آیتم):

{  "owner": "my-org",  "repo": "my-repo",  "title": "Bug: payment callback fails",  "body": "Steps to reproduce:n1) ...n2) ...",  "labels": ["bug", "payments"],  "assignees": ["ali-dev"]}

خروجی (Output)

خروجی بسته به عملیات، شیء بازگشتی GitHub API است (مثل Issue ایجادشده، لیست Issueها، اطلاعات Repository و…). n8n آن را به‌صورت item(s) برمی‌گرداند.

نمونه خروجی خلاصه‌شده برای Issue ایجادشده:

{  "id": 189234567,  "number": 42,  "title": "Bug: payment callback fails",  "state": "open",  "html_url": "https://github.com/my-org/my-repo/issues/42",  "labels": [    { "name": "bug" },    { "name": "payments" }  ],  "assignee": { "login": "ali-dev" },  "created_at": "2026-02-13T09:12:33Z"}

نکات پیشرفته و ترفندها

۱) استفاده از Expression برای داده‌های پویا

به‌جای مقدار ثابت، Owner/Repo/Title را از نودهای قبلی بخوانید. مثال: عنوان Issue را از موضوع ایمیل بگیرید و بدنه را از متن ایمیل بسازید.

۲) جلوگیری از ساخت آیتم تکراری (Deduplication)

  • قبل از Create Issue، یک عملیات List/Search انجام دهید و اگر Issue مشابه وجود داشت، به‌جای ساخت جدید، روی همان کامنت بگذارید یا آن را آپدیت کنید.
  • ترکیب پیشنهادی: GitHub (List Issues با فیلتر/جستجو) → IF (وجود داشت؟) → GitHub (Create Comment) / GitHub (Create Issue)

۳) مدیریت Rate Limit و بهینه‌سازی تعداد درخواست‌ها

  • در عملیات‌های لیستی، Return All را فقط زمانی روشن کنید که واقعاً لازم است.
  • از فیلترها (state، labels، since) برای کم کردن تعداد نتایج استفاده کنید.
  • اگر نیاز به پردازش تعداد زیاد آیتم دارید، از Split In Batches استفاده کنید تا فشار روی API کنترل شود.

۴) کار با Branch و SHA در عملیات فایل‌ها

برای Update فایل: ابتدا Get File برای دریافت SHA انجام دهید، سپس Update File را با همان SHA بزنید. این کار از تداخل نسخه‌ها جلوگیری می‌کند.

۵) استفاده ترکیبی با GitHub Trigger برای اتوماسیون رویدادمحور

  • PR opened → اجرای بررسی قوانین → کامنت خودکار
  • Issue labeled:urgent → ارسال پیام به On-call در Slack + ساخت Incident در ابزار دیگر

محدودیت‌ها و خطاها

محدودیت‌ها

  • محدودیت Rate Limit: GitHub برای درخواست‌ها محدودیت دارد و در اتوماسیون‌های پرترافیک باید batching و فیلترگذاری انجام شود.
  • سطح دسترسی Token: بسیاری از خطاها به‌خاطر permission ناکافی است (خصوصاً در Repoهای خصوصی یا سازمانی).
  • پوشش کامل API: ممکن است همه endpointهای GitHub در UI نود پوشش داده نشده باشند. در این حالت، استفاده از HTTP Request با GitHub API جایگزین رایج است.

خطاهای رایج و راه‌حل‌ها

  • 401 Unauthorized / 403 Forbidden

    علت: Token اشتباه، منقضی، یا دسترسی ناکافی.

    راه‌حل: Token را مجدد بسازید/به‌روزرسانی کنید و permissionهای لازم (Issues, Pull requests, Contents, Metadata) را فعال کنید.

  • 404 Not Found

    علت: Owner/Repo اشتباه یا Token به Repo دسترسی ندارد.

    راه‌حل: نام‌ها را بررسی کنید و مطمئن شوید Token به همان Repository دسترسی دارد.

  • 422 Unprocessable Entity

    علت: داده نامعتبر (مثلاً branch اشتباه، head/base نامعتبر، عنوان خالی، یا label ناموجود در برخی عملیات‌ها).

    راه‌حل: فیلدهای اجباری را کامل کنید، نام branchها را دقیق بزنید، و در صورت نیاز قبلش labelها را بسازید.

  • 409 Conflict (در عملیات فایل‌ها)

    علت: SHA صحیح ارائه نشده یا فایل هم‌زمان تغییر کرده است.

    راه‌حل: ابتدا فایل را Get کنید، SHA آخرین نسخه را بردارید، سپس Update کنید.

ایده ها

  • ساخت ربات «هشدار امنیتی»: هر زمان Dependabot Alert یا Security Advisory ثبت شد، یک Issue با اولویت بالا بسازد و به کانال امنیت Slack اطلاع دهد.
  • اتوماسیون انتشار: با تگ شدن نسخه (tag push)، Release ایجاد کند، فایل‌های build را آپلود کند و پیام انتشار را به ایمیل/Slack بفرستد.
  • گزارش روزانه توسعه: هر روز تعداد PRهای باز، Issueهای بسته‌شده و زمان پاسخ‌گویی را جمع کند و در یک فایل داخل Repo یا یک داشبورد ثبت کند.
  • فرآیند استاندارد باگ: هر تیکت ورودی از فرم سایت را به Issue با قالب ثابت (Environment, Steps, Expected/Actual) تبدیل کند و اتوماتیک label بزند.
  • Code Owners هوشمند: با تشخیص مسیر فایل‌های تغییر کرده در PR، Reviewerهای مناسب را پیشنهاد دهد یا کامنت راهنما ثبت کند.

منابع و مستندات اصلی

دسته بندی: N8N برچسب ها:

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

هجده − یک =