GitHub Actions: خودکارسازی CI از داخل مخزن
مفاهیم workflow، event، job، step، action و runner؛ CI ساده و نکات امنیتی طبق مستندات GitHub.
بنیانگذار و مهندس محصول

هر Pull Request بدون تست خودکار، به صبر reviewer و حافظهٔ توسعهدهنده وابسته است. GitHub Actions پلتفرم CI/CD توکار گیتهاب است: با یک فایل YAML در مخزن میتوانید روی push و PR بیلد بگیرید، تست اجرا کنید، ایمیج بسازید، یا حتی برچسب issue بزنید. طبق مستندات رسمی، Actions فراتر از DevOps است؛ هر رویداد مخزن میتواند گردشکار را روشن کند.
این مقاله واژگان اصلی، یک workflow تست حداقلی، و مرزهای امنیتی را میچیند تا YAML کپیشده از اینترنت بدون review وارد تولید نشود.

پاسخ کوتاه
در مسیر .github/workflows یک فایل YAML بگذارید که روی pull_request و push اجرا شود، روی runner گیتهاب (مثلاً ubuntu-latest) checkout کند، وابستگی نصب کند و تست را اجرا کند. Jobها مجموعهای از stepها هستند؛ step یا اسکریپت است یا action آماده. مقادیر حساس را در تنظیمات Secrets مخزن نگه دارید. وضعیت workflow میتواند به branch protection بهعنوان required check وصل شود.
Actions قدرت اتوماسیون است؛ YAML هم کد است و باید review شود.
اجزای اصلی طبق Docs
- Workflow: فرآیند خودکار تعریفشده در YAML داخل .github/workflows.
- Event: محرک مثل push، pull_request، schedule، workflow_dispatch.
- Job: مجموعه step روی یک runner؛ پیشفرض موازی مگر وابستگی تعریف شود.
- Step: یک دستور شل یا یک action.
- Action: واحد قابلاستفادهٔ مجدد (بازار یا خودتان).
- Runner: ماشین اجرای job — میزبانیشده توسط GitHub یا self-hosted.
اولین workflow تست
یک فایل YAML با نام دلخواه در مسیر workflows بسازید که روی push و pull_request به main اجرا شود.
الگوی حداقلی شامل checkout، نصب toolchain، نصب وابستگی از lockfile و اجرای تست است.
نام job را ساده و پایدار بگذارید تا در status check قابل ارجاع باشد.
گامهای رایج: بازیابی کد، آمادهسازی زبان، نصب از فایل قفل، سپس اجرای مجموعه تست.
نسخهٔ action را پین کنید؛ برچسب شناور بدون مرور ریسک تغییر ناگهانی دارد.
ماتریس، وابستگی job و آرتیفکت
با matrix میتوانید job را روی چند نسخه اجرا کنید. با needs وابستگی بسازید. artifact را برای فایلهای غیرحساس بین jobها منتقل کنید.
اسرار و متغیرها
مقادیر حساس را در Settings مخزن یا سازمان ذخیره کنید و از context رسمی در workflow بخوانید، نه بهصورت متن ثابت در YAML. در لاگ چاپ خام نکنید. برای deploy از Environments با قاعدهٔ حفاظتی استفاده کنید. پس از عمومی شدن مخزن، لاگ گردشکار دیدهتر میشود.
اتصال به کیفیت ادغام
نام job را پایدار نگه دارید و در branch protection آن را required کنید تا PR بدون تست سبز merge نشود. Docs هشدار میدهد نام job تکراری در چند workflow میتواند وضعیت را مبهم کند.
امنیت Actions به زبان ساده
- actionهای شخص ثالث را با نسخه یا SHA پین کنید.
- مدل دسترسی رویدادهای فورک را از مستندات رسمی بخوانید.
- runner خودمیزبان را روی مخازن عمومی بیمحافظت نگذارید.
- حداقل مجوز توکن گردشکار را در permissions مشخص کنید؛ مثلاً contents فقط read وقتی نوشتن لازم نیست.
yaml
permissions: contents: read
چه وقت Actions؛ چه وقت نه
| مناسب | نامناسب یا زود |
|---|---|
| تست و lint روی PR | جایگزین تست محلی صفر |
| انتشار پکیج با تگ | ساختهای بسیار طولانی بدون کش |
| اتوماسیون issue سبک | منطق تجاری پیچیده بدون مشاهدهپذیری |
عیبیابی روزمره
- تب Actions را برای لاگ step باز کنید.
- با workflow_dispatch دستی اجرا کنید.
- کش وابستگی را وقتی قفل عوض شده بازبینی کنید.
- شکست flaky را از شکست واقعی جدا کنید.
اشتباههای رایج
- کپی YAML بدون فهم triggers.
- گذاشتن credential داخل متن workflow.
- مجوز نوشتن گسترده برای توکن بدون نیاز.
- اتکا به برچسب latest شناور برای actionهای حیاتی.
- نادیده گرفتن هزینهٔ دقیقهٔ runner در سازمان بزرگ.
مسیر رشد بعدی
بعد از CI سبز: deploy به staging با environment protection، reusable workflows برای چند مخزن، و matrix تست.
خلاصه
GitHub Actions رویداد مخزن را به job روی runner وصل میکند. با یک workflow تست شروع کنید، مقادیر حساس را درست تزریق کنید، check را به حفاظت شاخه وصل کنید، و YAML را مثل کد تولیدی review کنید.
سوالات متداول
تفاوت action و workflow چیست؟
Workflow فایل فرآیند شماست؛ action واحد قابلاستفادهٔ مجدد که داخل step صدا زده میشود.
آیا به سرور خودمان نیاز است؟
برای شروع خیر؛ runnerهای GitHub کافیاند. خودمیزبان برای نیاز سختافزاری یا شبکهای خاص است.
چرا روی PR من workflow اجرا نشد؟
مسیر فایل YAML، نام شاخه در triggers، یا غیرفعال بودن Actions را چک کنید.
منابع و مراجع
- GitHub Docs — Understanding GitHub Actions: https://docs.github.com/en/actions/learn-github-actions/understanding-github-actions
- GitHub Docs — Workflow syntax: https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions
- GitHub Docs — Using secrets: https://docs.github.com/en/actions/security-guides/using-secrets-in-github-actions
- GitHub Docs — Security hardening for GitHub Actions: https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions
- GitHub Docs — About protected branches: https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches
نویسنده
سهیل ابراهیمپور بنیانگذار FutureForge است. روی طراحی محصول، معماری و استقرار نرمافزار سفارشی کار میکند.
یادداشتهای مرتبط
اگر در انتخاب معماری یا مسیر توسعه مطمئن نیستید، میتوانید درباره پروژه صحبت کنیم.
مسئله و محدودیت را بنویسید. اگر تطابق داشته باشیم، برای گفتگو هماهنگ میکنیم.




