گیت‌هاب اکشن‌ها(GitHub Actions) به شما انعطاف لازم برای ساخت ورک‌فلوهای(Workflow) خودکار چرخه توسعه نرم‌افزار را می‌دهند. شما می‌توانید وظایف جداگانه‌ای به نام اکشن بنویسید و آن‌ها را ترکیب کنید تا ورک‌فلوهای سفارشی در ریپازیتوری(Repository) خود ایجاد کنید. گیت‌هاب اکشن‌ها فرایندهای خودکاری هستند که به شما امکان ساخت، تست، بسته‌بندی، انتشار، یا استقرار هر پروژه ای روی گیت‌هاب را می‌دهند، همچنین می‌توانید از آن‌ها برای خودکارسازی هر استپ(Step) از ورک‌فلوی خود استفاده کنید. برای مثال: ادغام پول ریکوئست‌ها (Pull Request)، اختصاص برچسب‌ها(Tag) و اولویت‌بندی ایشو‌ها (Issue).

فایل‌های ورک‌فلو از سینتکس YAML استفاده می‌کنند، و باید پسوند فایل .yml یا .yaml داشته باشند. شما باید فایل‌های ورک‌فلو را در دایرکتوری github/workflows/. ذخیره کنید. هر فایل YAML نشان دهنده‌ی یک ورک‌فلوی ست.

name: My Workflow
on:
  push:
    branches:
      - 'releases/*'
      - '!releases/**-alpha'
env:
  message: 'conversation'
  my_token: ${{ secrets.GITHUB_TOKEN }}
jobs:
  my_build:
    runs-on: ubuntu-latest
    steps:
      - name: Checking out our code
        uses: actions/checkout@master
      - name: Say something
        run: |
          echo "A little less ${message}"
          echo "A little more action"
  my_job:
    needs: my_build
    container:
      image: node:10.16-jessie
      env:
        NODE_ENV: development
      ports:
        - 6379/tcp
      volumes:
        - my_docker_volume:/volume_mount
      options: --cpus 1
    services:
      redis:
        image: redis
        ports:
          - 6379/tcp

نام ورک‌فلوی شما در صفحه اکشن ‌های ریپازیتوری شما نمایش داده می‌شود.

نقشه‌ای از متغیرهای محیطی که می‌توانند در محدوده‌های مختلف تنظیم شوند. چندین متغیر محیطی به صورت پیش‌فرض در دسترس هستند (GITHUB_SHA ،GITHUB_REF ،GITHUB_EVENT_NAME ،HOME ،GITHUB_EVENT_PATH و ...) و همچنین یک secret به نام GITHUB_TOKEN که می‌توانید آن را برای فراخوانی‌های API یا دستورات git از طریق secrets استفاده کنید.

نوع رویدادی که ورک‌فلو را فعال می‌کند. شما می‌توانید یک یا آرایه‌ای از رویدادها، یا با پیکربندی رویداد‌ها اجرای ورک‌فلو را محدود کنید. به طور مثال:

• میتوان با استفاده از رویدادهای push و branches ،pull_request و tags انتخاب یا نادیده‌گرفتن (با پیشوند !) ورک‌فلو را مشخص کرد، این در حالی ست که paths مشخص می‌کند در صورت تغییر کدام فایل‌ها ورک‌فلو باید اجرا شود.
• اگر قوانین شما فقط از رویداد های عدم اجرا ست، می‌توانید از branches-ignore، tags-ignore و paths-ignore استفاده کنید. نمی‌توان حالت نادیده‌گیری -ignore را با حالت شامل کردن (include) به‌صورت هم‌زمان استفاده کرد.
• کلیدواژه‌ی types به شما این امکان را می‌دهد که مشخص کنید کدام نوع از فعالیت‌ها (مثل opened، created، edited و …) باعث اجرای ورک‌فلو شوند. فهرست فعالیت‌های قابل استفاده، بسته به نوع رویداد متفاوت است.

همچنین اجرا شدن یک ورک‌فلو می‌تواند برنامه‌ریزی شود:

schedule:
  - cron: '*/15 * * * *'

اجرای ورک‌فلو از یک یا چند جاب تشکیل شده که با یک job_id منحصر به فرد شناسایی می‌شوند (my_build یا my_job). جاب‌ها به صورت پیش‌فرض به صورت موازی(Parallel) اجرا می‌شوند مگر اینکه با ویژگی needs در صف قرار گیرند. هر جاب در یک نمونه(instance) تازه از محیط مجازی مشخص شده توسط runs-on اجرا می‌شود.

نام جاب که در گیت‌هاب نمایش داده می‌شود.

هر جابی که باید قبل از اجرای این جاب با موفقیت تکمیل شود را شناسایی می‌کند. می‌تواند یک یا آرایه‌ای از جاب ها باشد. اگر یک جاب شکست بخورد، تمام جاب‌هایی که به آن نیاز دارند رد می‌شوند مگر اینکه جاب‌ها از یک عبارت شرطی استفاده کنند که باعث ادامه جاب شود.

نوع ماشین هاست مجازی برای اجرای جاب. می‌تواند یک رانر گیت‌هاب یا self-hosted باشد. جاب‌ها همچنین می‌توانند در کانتینرهای مشخص شده توسط کاربر اجرا شوند. انواع ماشین‌های مجازی موجود در گیت‌هاب: ubuntu-latest، windows-latest، macOS-latest. به علاوه برخی نسخه‌های خاص دیگر برای هر سیستم عامل، به شکل windows-xxxx، macOS-XX.XX یا ubuntu-xx.xx هستند. برای مشخص کردن یک رانر self-hosted برای جاب خود، runs-on را در فایل ورک‌فلوی خود با برچسب‌های رانر self-hosted پیکربندی کنید. مثال: [self-hosted, linux].

به‌جای اجرای مراحل روی هاستی که با runs-on مشخص شده است، می‌توان مراحل یک job را داخل یک کانتینر اجرا کرد. در این حالت، تمام مراحلی که کانتینر جداگانه‌ای مشخص نکرده‌اند، داخل همین کانتینر اجرا می‌شوند. اگر در یک job از هر دو نوع script step و container استفاده شود، کانتینرهای مربوط به actionها به‌صورت کانتینرهای هم‌رده (sibling) اجرا می‌شوند؛ این کانتینرها روی یک شبکهٔ مشترک قرار دارند و از همان volume mountها استفاده می‌کنند. این شیء شامل ویژگی‌های زیر است: image، env، ports، volumes و options.

حداکثر دقایقی که به یک ورک‌فلو اجازه اجرا داده می‌شود قبل از اینکه گیت‌هاب به طور خودکار آن را لغو کند. پیش‌فرض: 360

کانتینر هایی برای میزبانی سرویس‌ها در یک جاب در یک ورک‌فلو. این‌ها برای ایجاد دیتابیس یا سرویس‌های کش مفید هستند. رانر روی ماشین مجازی به طور خودکار یک شبکه ایجاد کرده و چرخه حیات کانتینر های سرویس‌ را مدیریت می‌کند. هر سرویس یک شیء نام‌گذاری شده در مجموعه services است (برای مثال redis یا nginx) و می‌تواند پارامترهای مشابه شیء container را دریافت کند.

هر جاب شامل مجموعه‌ای از وظایف به نام استپ است. هر استپ می‌تواند دستوری را اجرا کند، کارهای آماده‌سازی را انجام دهد، یا یک اکشن را اجرا کند؛ این اکشن می‌تواند از مخزن خودتان، یک مخزن عمومی، یا از اکشنی که در یک داکر ریجستری منتشر شده باشد استفاده کند. هر استپ در یک پردازش جداگانه داخل محیط مجازی اجرا می‌شود، اما به ورک اسپیس و سیستم فایل مشترک دسترسی دارد.

برچسبی که نام استپ را در گیت‌هاب مشخص میکند. این مورد الزامی نیست اما خوانایی را در لاگ‌ها بهبود می‌بخشد.

یک اکشن را برای اجرا به عنوان بخشی از یک استپ در جاب خود مشخص کنید. شما می‌توانید از یک اکشن تعریف شده در همان ریپازیتوری ورک‌فلو، یک ریپازیتوری عمومی در جای دیگر گیت‌هاب، یا در یک داکر کانتینر image منتشر شده استفاده کنید. شامل کردن نسخه اکشن که استفاده می‌کنید با مشخص کردن یک Git ref، branch، SHA، یا Docker tag به شدت توصیه می‌شود:

از uses برای مشخص کردن اکشنی که باید به‌عنوان بخشی از یک step در job اجرا شود استفاده می‌شود. این اکشن می‌تواند در همان مخزنی باشد که ورک‌فلو در آن قرار دارد، در یک مخزن عمومی دیگر در گیت‌هاب یا به‌صورت یک ایمیج منتشرشده در داکرهاب باشد. به‌شدت توصیه می‌شود نسخه‌ی اکشنی که استفاده می‌کنید را مشخص کنید؛ این کار با تعیین Git ref، branch، SHA یا Docker tag انجام می‌شود.

نمونه‌های استفاده:

• اکشن‌های موجود در یک مخزن عمومی:

  uses: {owner}/{repo}@{ref}

• اکشن‌های داخل یک زیرشاخه از یک مخزن عمومی:

  uses: {owner}/{repo}/{path}@{ref}

• اکشن‌های داخل یک زیرشاخه از همان مخزن فعلی:

  uses: ./path/to/dir

• اکشن‌های مبتنی بر Docker در Docker Hub:

  uses: docker://{image}:{tag}

• اکشن‌های مبتنی بر Docker در یک registry عمومی:

  uses: docker://{host}/{image}:{tag}

یک map از پارامترهای ورودی تعریف شده توسط اکشن در فایل action.yml آن. وقتی اکشن مبتنی بر کانتینر است، نام‌های پارامتر خاص عبارتند از:

• args: رشته‌ای که ورودی‌های ارسال شده به ENTRYPOINT یک داکر کانتینر را تعریف می‌کند. این به جای دستور العمل CMD درDockerfile استفاده می‌شود.
• entrypoint: رشته‌ای که فایل اجرایی برای اجرا به عنوان ENTRYPOINT یک داکر کانتینر را تعریف یا بازنویسی می‌کند.

جلوگیری از اجرای یک استپ مگر اینکه شرطی برآورده شود. مقدار یک expression بدون بلوک ${{ ... }} است. به جای اجرای یک اکشن موجود، یک برنامه خط فرمان می‌تواند با استفاده از شل سیستم عامل اجرا شود. هر کلیدواژه run نشان‌دهنده یک پراسس و شل جدید در محیط مجازی است. یک شل خاص می‌تواند با ویژگی shell انتخاب شود. چندین دستور می‌توانند در یک نمونه شل واحد با استفاده از عملگر پایپ | اجرا شوند.

یک استراتژی build matrix مجموعه‌ای از پیکربندی‌های مختلف محیط مجازی است. مجموعه استپ‌ها مربوط به جاب روی هر یک از این پیکربندی‌ها اجرا خواهد شد. مثال زیر ۳ نسخه nodejs را روی ۲ سیستم عامل مشخص می‌کند:

runs-on: ${{ matrix.os }}
strategy:
  matrix:
    os: [ubuntu-16.04, ubuntu-18.04]
    node: [6, 8, 10]
steps:
  - uses: actions/setup-node@v1
    with:
      node-version: ${{ matrix.node }}

وقتی روی true تنظیم شود (مقدار پیش‌فرض)، اگر هر یک از جاب های ماتریس شکست بخورد، گیت‌هاب تمام جاب های در حال انجام را لغو می‌کند.

Expressions می‌توانند برای تنظیم برنامه‌نویسی‌شده متغیرها در فایل‌های ورک‌فلو و دسترسی به contextها استفاده شوند. یک expression می‌تواند هر ترکیبی از مقادیر لفظی (literal)، ارجاعات به یک context، یا توابع باشد. شما می‌توانید literals، ارجاعات context، و توابع را با استفاده از عملگرها ترکیب کنید. به استثنای کلید if، عبارت‌ها (expressions) در یک بلوک ${{ ... }} نوشته می‌شوند. Contextها اشیائی هستند که دسترسی به اطلاعات زمان اجرا (runtime) را فراهم می‌کنند. اشیاء زیر در دسترس هستند: github، job، steps، runner، secrets، strategy و matrix.

یک artifact فایل یا مجموعه‌ای از فایل‌هاست که در طول اجرای یک ورک‌فلو تولید شده و می‌تواند ذخیره شود و بین jobها در یک اجرای ورک‌فلو به اشتراک گذاشته شود. از اکشن ‌های actions/upload-artifact و actions/download-artifact با پارامترهای name و path برای دستکاری artifactها استفاده کنید. Artifactها می‌توانند از طریق رابط وب به مدت ۹۰ روز دانلود شوند.

برای وابستگی‌ها (dependencies) و سایر فایل‌هایی که معمولاً در اجراهای یک ورک‌فلو خاص استفاده مجدد می‌شوند، از اکشن با نام actions/cache با پارامترهای زیر استفاده کنید: key: کلید استفاده شده برای ذخیره و جستجوی یک cache. path: مسیر فایل (مطلق یا نسبی نسبت به دایرکتوری کاری) روی رانر برای cache یا restore کردن. restore-keys: اختیاری - یک لیست مرتب شده از کلیدهای جایگزین برای استفاده جهت یافتن cache اگر هیچ cache hit برای key رخ نداد.

uses: actions/checkout@v1
name: Cache node modules
uses: actions/cache@v1
with:
  path: node_modules
  key: x-y-${{hashFiles('**/package-lock.json')}}
  restore-keys:
    x-y-