GitHub Actions — یہ کیا ہے، CI/CD پائپ لائنز اور آٹومیشن

GitHub Actions کیا ہے؟

GitHub Actions GitHub میں شامل ایک ورک فلو آٹومیشن پلیٹ فارم ہے جو 2019 میں شروع کیا گیا تھا۔ یہ آپ کو YAML فائلوں میں CI/CD پائپ لائنز کی وضاحت کرنے کی اجازت دیتا ہے جو براہ راست ریپوزٹری میں محفوظ ہوتی ہیں۔ ہر ورک فلو ایک واقعہ سے متحرک ہوتا ہے: push، pull request، ٹیگ کی تخلیق یا شیڈول کے مطابق۔ Jenkins یا TeamCity کے برعکس، CI سرور کی میزبانی کے لیے علیحدہ انفراسٹرکچر کی ضرورت نہیں ہے۔

موبائل ڈیولپمنٹ کے تناظر میں، GitHub Actions APK اور IPA بلڈ، ایمولیٹرز پر یونٹ ٹیسٹ اور UI ٹیسٹ چلانے، لنٹرز کے ذریعے کوڈ کی جانچ، دستخط اور Google Play اور App Store میں اشاعت کو خودکار کرتا ہے۔ پلیٹ فارم مفت منٹ فراہم کرتا ہے عوامی ریپوزٹریز کے لیے اور نجی کے لیے قیمتوں کے منصوبے کے مطابق۔ اوپن سورس موبائل پروجیکٹس کے لیے، یہ بغیر کسی لاگت کے ایک مکمل CI/CD حل ہے۔

GitHub Actions کا فن تعمیر: Workflows، Jobs اور Steps

GitHub Actions کا فن تعمیر چار سطحوں پر مشتمل ہے۔ Workflow روٹ YAML فائل ہے جو آٹومیشن کی وضاحت کرتی ہے۔ Workflow Jobs پر مشتمل ہوتا ہے، ہر Job ایک علیحدہ Runner پر چلتی ہے۔ Job کے اندر Steps انجام دیے جاتے ہیں — ترتیب وار کمانڈز یا بیرونی ایکشنز۔ Events محرکات کی وضاحت کرتے ہیں: push، pull_request، schedule، workflow_dispatch۔ GitHub انٹرفیس میں Actions ٹیب کے ذریعے ورک فلو کو دستی طور پر بھی متحرک کیا جا سکتا ہے۔

GitHub پہلے سے نصب OS کے ساتھ میزبانی شدہ runners فراہم کرتا ہے: Ubuntu، macOS اور Windows۔ iOS بلڈز کے لیے macOS-runner لازمی ہے، Android کے لیے — Linux یا macOS۔ Self-hosted runners آپ کو اپنے سرورز پر حسب ضرورت ماحول کے ساتھ jobs چلانے کی اجازت دیتے ہیں، جو خصوصی ہارڈویئر ضروریات والے بڑے پروجیکٹس کے لیے مفید ہے۔ GitHub jobs پر عملدرآمد کی قطاروں کو منظم کرنے کے لیے self-hosted runner گروپس بھی سپورٹ کرتا ہے۔

ورک فلو فائل کی ساخت

بنیادی ورک فلو فائل میں سیکشنز ہوتے ہیں: name، on (محرکات)، jobs۔ ہر job runs-on (runner کی قسم)، strategy (میٹرکس)، steps (ایکشنز کی فہرست) بتاتا ہے۔ Steps شیل کمانڈز یا مارکیٹ پلیس سے تیار ایکشنز ہو سکتے ہیں، جو owner/repo@version نحو کے ذریعے منسلک ہوتے ہیں۔

GitHub Actions میں موبائل ایپلیکیشنز کی بلڈ

Android بلڈز کے لیے، ورک فلو میں عام طور پر اقدامات شامل ہوتے ہیں: ریپوزٹری کا checkout، JDK انسٹالیشن، Gradle کیش کنفیگریشن، assembleRelease چلانا۔ iOS کے لیے macOS-runner کی ضرورت ہے، xcode-select کے ذریعے Xcode انسٹالیشن، provisioning profile کا حل اور xcodebuild چلانا۔ iOS بلڈز کی پیچیدگی کوڈ سائننگ اور سرٹیفکیٹ مینجمنٹ میں ہے۔ Apple کی مخصوص ترتیبات میں apple-actions/import-codesign-certs کے ذریعے provisioning profile مینجمنٹ شامل ہے۔

Matrix strategy ایک ساتھ متعدد ورژنز پر بلڈز چلانے کی اجازت دیتی ہے۔ مثال کے طور پر: iOS ورژنز (15.0، 16.0، 17.0) اور Xcode (14، 15) کے ساتھ میٹرکس۔ یہ تصدیق کو تیز کرتا ہے مختلف OS ورژنز کے ساتھ ایپلیکیشن کی مطابقت کی، اگرچہ یہ runner منٹس کی کھپت بڑھاتا ہے۔ محدود CI بجٹ والے پروجیکٹس کے لیے، میٹرکس صرف اہم کنفیگریشنز تک محدود کیا جا سکتا ہے۔

Android کے لیے ماحول ترتیب دینا

GitHub Actions JDK انسٹالیشن کے لیے setup-java ایکشن اور Gradle کیشنگ کے لیے caching فراہم کرتا ہے۔ Android SDK Ubuntu runners پر پہلے سے نصب ہے۔ حسب ضرورت API لیولز کے لیے، ایک علیحدہ مرحلے میں sdkmanager استعمال کیا جاتا ہے۔ Android اور iOS بلڈز کے لیے علیحدہ ورک فلو بنانے کی سفارش کی جاتی ہے، کیونکہ وہ مختلف runners اور بلڈ ٹولز استعمال کرتے ہیں۔

GitHub Marketplace اور تیار ایکشنز

GitHub Marketplace میں کمیونٹی اور سرکاری ڈیولپرز کے ذریعے تخلیق کردہ 15,000 سے زیادہ ایکشنز ہیں۔ موبائل ڈیولپمنٹ کے لیے، اہم زمروں میں شامل ہیں: کوڈ سائننگ (apple-actions/import-codesign-certs)، ٹیسٹنگ (react-native-community/action)، ڈیپلائمنٹ (google-github-actions/release-google-play)، اطلاعات (slackapi/slack-github-action)۔ Firebase App Distribution، TestUpload اور Fastlane کے لیے بھی ایکشنز دستیاب ہیں۔ ہر ایکشن میں ایک مخصوص runner OS کے ساتھ مطابقت کا لیبل ہوتا ہے۔

ہر ایکشن کا ایک ورژن، تفصیل، README اور لائسنس ہوتا ہے۔ ایکشن منتخب کرتے وقت، وینڈرز (Google، Apple، Microsoft) سے سرکاری اور Verified Badge کے ذریعے تصدیق شدہ کو ترجیح دی جانی چاہیے۔ ایک مقررہ میجر ورژن بتانا ضروری ہے (actions/checkout@v4)، @main نہیں، غیر متوقع تبدیلیوں سے بچنے کے لیے۔ اگر مطلوبہ ایکشن Marketplace میں نہیں ہے، تو آپ ایک حسب ضرورت ایکشن بنا سکتے ہیں — مقامی طور پر ریپوزٹری میں (Docker action یا JavaScript action) یا Marketplace میں شائع کر سکتے ہیں۔

موبائل CI/CD کے لیے مشہور ایکشنز

• actions/checkout — ریپوزٹری کو runner میں کلون کرتا ہے
• actions/setup-java — Android بلڈز کے لیے JDK انسٹال کرتا ہے
• gradle/actions/setup-gradle — Gradle کو کنفیگر اور کیش کرتا ہے
• apple-actions/import-codesign-certs — iOS کے لیے سرٹیفکیٹ درآمد کرتا ہے
• google-github-actions/submit-release — Google Play Console میں شائع کرتا ہے

iOS پروجیکٹ کے لیے ورک فلو کی مثال

iOS ایپلیکیشنز تیار کرتے وقت، سمیلیٹرز اور آلات کے ساتھ درست کام ترتیب دینا ضروری ہے۔ macOS-14 runner ARM فن تعمیر پر Intel بلڈز چلانے کے لیے Rosetta 2 کے ساتھ ماحول فراہم کرتا ہے۔ ایک ورک فلو میں متعدد بلڈ اسکیمیں شامل ہو سکتی ہیں — pull request کے لیے Debug اور ٹیگ کے لیے Release۔ GitHub Actions ٹیسٹ کے نتائج ظاہر کرنے کے لیے xcparse/sonarqube ایکشن کے ذریعے xcresult پارسنگ کو سپورٹ کرتا ہے۔ بلڈ اسٹیٹس اطلاعات بھیجنے کے لیے، Slack یا Telegram ایکشن شامل کیا جا سکتا ہے۔

iOS کے لیے کوڈ سائننگ میں سرٹیفکیٹ اور provisioning profiles درآمد کرنا شامل ہے۔ Apple-actions فراہم کرتا ہے P12 سرٹیفکیٹ درآمد کرنے اور provisioning profile انسٹال کرنے کا ایک مرحلہ۔ سرٹیفکیٹ GitHub Actions secrets کے طور پر محفوظ ہوتے ہیں اور صرف بلڈ مرحلے میں ڈکرپٹ کیے جاتے ہیں۔ دستخط آٹومیشن کے لیے Fastlane match استعمال کیا جاتا ہے، جسے ورک فلو میں علیحدہ مرحلے کے طور پر کال کیا جا سکتا ہے۔

Swift میں iOS ایپ کے لیے ایک ورک فلو پر غور کریں جو پروجیکٹ بناتا ہے، ٹیسٹ چلاتا ہے اور ایک آرکائیو شدہ بلڈ تخلیق کرتا ہے۔ ورک فلو استعمال کرتا ہے macOS-14 runner، Xcode 15.4 اور سرٹیفکیٹ مینجمنٹ کے لیے ایکشنز۔

name: iOS CI

on:
  push:
    branches: ["main"]
  pull_request:
    branches: ["main"]

jobs:
  build:
    runs-on: macos-14
    steps:
      - uses: actions/checkout@v4
      - name: Select Xcode
        run: sudo xcode-select -s /Applications/Xcode_15_4.app
      - name: Install CocoaPods
        run: pod install
      - name: Build and test
        run: xcodebuild clean test -workspace App.xcworkspace
            -scheme App -sdk iphonesimulator
      - name: Archive
        run: xcodebuild archive -workspace App.xcworkspace
            -scheme App -archivePath App.xcarchive

GitHub Actions میں انحصار کیشنگ

کیشنگ ورک فلو رنز کے درمیان انحصار کو محفوظ رکھ کر بلڈ وقت کو کم کرتی ہے۔ GitHub فراہم کرتا ہے actions/cache کے ذریعے بلٹ ان کیشنگ۔ Gradle کے لیے، ~/.gradle کیش کیا جاتا ہے، CocoaPods کے لیے — Pods/، SPM کے لیے — .build/۔ کیش کلید میں انحصار کی فہرست والی فائل کا ہیش شامل ہوتا ہے — جب انحصار تبدیل ہوتا ہے، کیش خود بخود باطل ہو جاتی ہے۔

کیش بحالی کی حکمت عملی (restore-keys) پر خصوصی توجہ دینی چاہیے۔ اگر صحیح کلید نہ ملے تو GitHub Actions restore-keys کے ذریعے جزوی مماثلت آزماتا ہے۔ یہ مفید ہے جب صرف ایک انحصار تبدیل ہوتا ہے — کیش جزوی طور پر قابل استعمال رہتی ہے۔ Gradle کے لیے، مزید برآں Gradle Build Cache کو فعال کرنے کی سفارش کی جاتی ہے، جو پروجیکٹ کے مختلف ماڈیولز کے درمیان بلڈ نتائج کو کیش کرتی ہے۔

Gradle کیشنگ کی مثال

- name: Cache Gradle
  uses: actions/cache@v4
  with:
    path: |
      ~/.gradle/caches
      ~/.gradle/wrapper
    key: ${{ runner.os }}-gradle-${{ hashFiles('*.gradle*') }}

کیش کی کارکردگی Android پروجیکٹس کے لیے: کیش کے بغیر پہلی بلڈ — 8–12 منٹ، کیش کے ساتھ بعد کی بلڈ — 2–4 منٹ۔ CocoaPods کے ساتھ iOS کے لیے، بچت اسی طرح ہے۔ بہترین کیش مینجمنٹ کے لیے actions/cache کو Gradle کے setup-gradle ایکشن کے ساتھ جوڑنے کی سفارش کی جاتی ہے۔ React Native میں npm انحصار کے لیے، package-lock.json ہیشنگ کے ساتھ actions/cache استعمال کیا جاتا ہے۔ مناسب کیش کنفیگریشن کے ساتھ، بلڈ وقت کو 70% تک کم کیا جا سکتا ہے۔

GitHub Actions ورک فلو، job اور step سطح پر ماحولیاتی متغیرات کو سپورٹ کرتا ہے۔ ماحولیاتی متغیرات کو اوور رائڈ کیا جا سکتا ہے: step-سطح کی سب سے زیادہ ترجیح ہوتی ہے۔ خفیہ ڈیٹا کے لیے، ہمیشہ secrets استعمال کریں — وہ AES-256 سے انکرپٹ ہوتے ہیں اور لاگز میں ظاہر نہیں ہوتے۔ ماحولیاتی تحفظ کے قواعد بھی دستیاب ہیں — ڈیپلائمنٹ سے پہلے لازمی دستی منظوری۔ اضافی سیکیورٹی کے لیے، مخصوص صارفین یا ٹیموں سے لازمی منظوری ترتیب دی جا سکتی ہے۔

GitHub Actions Reusable Workflows کو بھی سپورٹ کرتا ہے — دوبارہ قابل استعمال پائپ لائنز جنہیں دوسرے ورک فلو سے کال کیا جا سکتا ہے۔ یہ اجازت دیتا ہے ایک مرکزی بلڈ ورک فلو بنانے اور اسے تنظیم کی تمام ریپوزٹریز میں دوبارہ استعمال کرنے کی۔ Reusable workflow ایک لائن میں کال کیا جاتا ہے اور ان پٹ پیرامیٹرز اور secrets قبول کر سکتا ہے۔ یہ بڑی ٹیموں میں CI/CD طریقوں کو معیاری بنانے کے لیے خاص طور پر مفید ہے۔

سیکیورٹی اور بہترین طریقے

موبائل پروجیکٹس کے لیے GitHub Actions ترتیب دیتے وقت، سیکیورٹی اصولوں پر عمل کرنا ضروری ہے۔ OIDC (OpenID Connect) آپ کو طویل مدتی اسناد ختم کرنے اور کلاؤڈ فراہم کنندگان کے لیے عارضی ٹوکن حاصل کرنے کی اجازت دیتا ہے۔ اسکرپٹس میں کبھی بھی عام متن میں secrets استعمال نہ کریں — GitHub Actions خود بخود لاگز میں secrets کو ماسک کرتا ہے۔

موبائل پروجیکٹس کے لیے، تیسرے فریق کے forks کے لیے ورک فلو تک رسائی کو محدود کرنا ضروری ہے۔ pull_request_target ترتیب کو احتیاط سے استعمال کریں — یہ fork سے نہیں، بنیادی برانچ سے کوڈ چلاتا ہے۔ iOS ایپ کوڈ سائننگ کے لیے، سرٹیفکیٹ کو انکرپٹڈ شکل میں محفوظ کرنے اور صرف بلڈ مرحلے میں gpg یا openssl کے ذریعے ڈکرپٹ کرنے کی سفارش کی جاتی ہے۔