VPS پر GitHub Actions Runner کیسے انسٹال کریں

خود میزبان GitHub Actions رنر کیا کرتا ہے

خود میزبان GitHub Actions رنر ایک ایسا پروگرام ہے جسے آپ اپنے VPS پر انسٹال کرتے ہیں۔ یہ GitHub سے جابز (jobs) طلب کرتا ہے اور انہیں آپ کے ہارڈویئر پر چلاتا ہے۔ آپ اسے ایک ریپوزٹری کے ساتھ رجسٹر کرتے ہیں، اسے systemd سروس کے طور پر انسٹال کرتے ہیں، اور یہ ہر ریبوٹ کے بعد خود بخود دوبارہ چل پڑتا ہے۔ GitHub جاب کو شیڈول کرتا ہے، جبکہ آپ کا سرور کام انجام دیتا ہے۔

اپنی ملکیت والے سرور پر CI (مسلسل انٹیگریشن) دو وجوہات کی بنا پر فائدہ مند ہے۔ بلڈ منٹس (build minutes) کی پیمائش ختم ہو جاتی ہے، اور ایک جاب ایسی چیزوں تک رسائی حاصل کر سکتی ہے جو صرف آپ کی مشین کے پاس ہیں، جیسے کہ وارم بلڈ کیش (warm build cache) یا پرائیویٹ نیٹ ورک۔ اس کی قیمت سیکیورٹی ہے۔ رنر ورک فلو فائل میں درج ہر چیز کو اسی صارف کے طور پر چلاتا ہے جو آپ نے اسے دیا ہے، لہذا ورک فلو فائل ڈیزائن کے لحاظ سے ریموٹ کوڈ ایگزیکیوشن (remote code execution) ہے۔ پرائیویٹ ریپوزٹری پر یہ ٹھیک ہے، کیونکہ صرف وہی لوگ اسے شامل کر سکتے ہیں جن پر آپ بھروسہ کرتے ہیں۔ پبلک ریپوزٹری پر یہ ایک حقیقی خطرہ ہے، اور fork pull requests پر موجود سیکشن اس کے طریقہ کار کی وضاحت کرتا ہے۔

ذیل میں دی گئی ہر چیز Ubuntu 24.04 اور رنر ورژن 2.336.0 کے ساتھ ہے، جو جولائی 2026 تک کا موجودہ ریلیز ہے۔

شروع کرنے سے پہلے آپ کو کیا درکار ہے

ایک ایسے VPS سے شروعات کریں جس میں ایک عام ایڈمن اکاؤنٹ اور sudo موجود ہو، یہ وہ حالت ہے جو آپ نئے VPS پر پہلے دس منٹ میں حاصل کرتے ہیں۔ آپ کو کوئی ان باؤنڈ پورٹ کھولنے کی ضرورت نہیں ہے۔ رنر GitHub کے ساتھ ایک آؤٹ باؤنڈ HTTPS (ہائپر ٹیکسٹ ٹرانسفر پروٹوکول سیکیور) کنکشن کھولتا ہے اور کام کے انتظار میں اسے کھلا رکھتا ہے، لہذا GitHub کبھی بھی آپ کے سرور سے براہ راست کنیکٹ نہیں ہوتا ہے۔ آپ کا فائر وال دنیا کے لیے بند رہ سکتا ہے اور جابز پھر بھی موصول ہوتی رہیں گی۔

آپ کو ریپوزٹری پر ایڈمن حقوق کی بھی ضرورت ہے، کیونکہ رجسٹریشن ٹوکن ریپوزٹری کی ترتیبات (settings) میں دکھایا جاتا ہے۔

رنر کے لیے ایک مخصوص صارف بنائیں

رنر کو کبھی بھی root یا اپنے ایڈمن صارف کے طور پر نہ چلائیں۔ ہر جاب رنر صارف کے حقوق حاصل کر لیتی ہے، لہذا اگر رنر صارف sudo استعمال کر سکتا ہے تو sudo کو کال کرنے والا ورک فلو کامیاب ہو جائے گا۔ ایک ایسا غیر مراعات یافتہ (unprivileged) صارف بنائیں جس کی ملکیت میں اس کی ہوم ڈائریکٹری کے سوا کچھ نہ ہو۔ VPS پر کم سے کم مراعات والے صارف اکاؤنٹس عمومی طریقہ کار کا احاطہ کرتا ہے۔ یہاں مخصوص طریقہ درج ہے۔

sudo useradd -m -s /bin/bash gharunner
sudo passwd -l gharunner
sudo chmod 750 /home/gharunner
sudo install -d -m 700 -o gharunner -g gharunner /home/gharunner/actions-runner

passwd -l پاس ورڈ کو لاک کر دیتا ہے، تاکہ کوئی بھی اس کے ذریعے gharunner کے طور پر لاگ ان نہ ہو سکے۔ رنر ڈائریکٹری پر 700 موڈ اہم ہے کیونکہ رنر وہاں اپنی اسناد (credentials) کو سادہ متن (cleartext) میں محفوظ کرتا ہے، اور چیک آؤٹ میں نجی سورس کوڈ ہو سکتا ہے۔

مزید آگے بڑھنے سے پہلے دونوں خصوصیات کی جانچ کریں:

sudo passwd -S gharunner
sudo -l -U gharunner

passwd -S ایک لائن پرنٹ کرتا ہے جو gharunner L سے شروع ہوتی ہے، جہاں L کا مطلب ہے کہ پاس ورڈ لاک ہے۔ sudo -l -U gharunner کو is not allowed to run sudo کے ساتھ جواب دینا چاہیے۔ اگر یہ اس کے بجائے اجازت یافتہ کمانڈز کی فہرست پرنٹ کرتا ہے، تو اکاؤنٹ sudo گروپ میں ہے اور جو تنہائی (isolation) آپ نے ابھی بنائی ہے وہ ختم ہو چکی ہے۔

رنر ڈاؤن لوڈ کریں اور ٹار بال (tarball) کی جانچ کریں

یہاں سے بطور runner صارف کام کریں۔

sudo -iu gharunner
cd ~/actions-runner
RUNNER_VERSION=2.336.0
curl -fL -o actions-runner-linux-x64-${RUNNER_VERSION}.tar.gz \
  "https://github.com/actions/runner/releases/download/v${RUNNER_VERSION}/actions-runner-linux-x64-${RUNNER_VERSION}.tar.gz"

اگر آپ کو آرکیٹیکچر کے بارے میں یقین نہیں ہے تو پہلے uname -m چلائیں۔ x86_64 اوپر دی گئی linux-x64 فائل لیتا ہے۔ aarch64 میں actions-runner-linux-arm64-${RUNNER_VERSION}.tar.gz استعمال ہوتا ہے۔

اب تصدیق کریں کہ آپ نے کیا ڈاؤن لوڈ کیا ہے۔ نیچے دیا گیا SHA256 (سیکیور ہیش الگورتھم، 256 بٹ) 2.336.0 x64 ٹار بال کے لیے ہے۔ GitHub موجودہ ریلیز کے لیے ریلیز کے صفحے پر اور New self-hosted runner اسکرین پر اس کی ویلیو ظاہر کرتا ہے۔ یہ ہر ورژن کے ساتھ تبدیل ہوتی ہے، لہذا جب آپ کوئی مختلف ورژن انسٹال کریں تو اسے وہیں سے کاپی کریں۔

echo "04cf0be1aff4c3ec3554466c39124ca250e3effd8873bb7e8d68535aa9505d5d  actions-runner-linux-x64-2.336.0.tar.gz" | sha256sum -c

ایک درست ڈاؤن لوڈ ایک لائن پرنٹ کرتا ہے:

actions-runner-linux-x64-2.336.0.tar.gz: OK

ایک نامکمل یا تبدیل شدہ فائل ناکامی اور انتباہ پرنٹ کرتی ہے:

actions-runner-linux-x64-2.336.0.tar.gz: FAILED
sha256sum: WARNING: 1 computed checksum did NOT match

اس جانچ کو نظر انداز نہ کریں اور tar کو مسئلہ تلاش کرنے نہ دیں۔ ایک ادھورا لکھا ہوا آرکائیو gzip: stdin: unexpected end of file اور tar: Unexpected EOF in archive کے ساتھ ناکام ہو جاتا ہے، جو آپ کو بتاتا ہے کہ فائل خراب ہے لیکن یہ نہیں بتاتا کہ آیا یہ کٹ گئی تھی یا اسے تبدیل کر دیا گیا ہے۔

tar xzf ./actions-runner-linux-x64-2.336.0.tar.gz
ls

ٹار بال (tarball) میں کیا شامل ہے، اور کیا نہیں

ایکسٹریکشن کے بعد ڈائریکٹری میں config.sh، run.sh، env.sh، safe_sleep.sh، bin/ اور externals/ موجود ہوتے ہیں۔ bin/ میں رنر بائنریز اور bin/installdependencies.sh موجود ہوتے ہیں۔ externals/ میں بنڈل شدہ Node رن ٹائم موجود ہوتا ہے جس پر JavaScript ایکشنز عمل کرتی ہیں۔

ابھی تک یہاں کوئی svc.sh موجود نہیں ہے۔ GitHub کی دستاویزات اسے اسکرپٹ کے طور پر بیان کرتی ہیں "جو رنر کو کامیابی سے شامل کرنے کے بعد تخلیق ہوتا ہے"، کیونکہ یہ ایک ٹیمپلیٹ سے لکھا جاتا ہے جس میں آپ کی ریپوزٹری اور رنر کا نام سروس کے نام کے طور پر شامل ہوتا ہے۔ لہذا ./config.sh سے پہلے sudo ./svc.sh install چلانے پر sudo: ./svc.sh: command not found کی خرابی ظاہر ہوتی ہے۔ پہلے رجسٹر کریں، پھر سروس انسٹال کریں۔

رنر کی انحصاریاں (dependencies) انسٹال کریں

رنر ایک .NET ایپلیکیشن ہے، اس لیے اسے چند مشترکہ لائبریریوں کی ضرورت ہوتی ہے۔ رنر صارف کی شیل سے باہر نکلیں اور انہیں sudo کے ساتھ انسٹال کریں، کیونکہ اسکرپٹ سسٹم پیکیج ڈیٹا بیس میں لکھتا ہے۔

exit
cd /home/gharunner/actions-runner
sudo ./bin/installdependencies.sh

Ubuntu 24.04 پر یہ libkrb5-3، zlib1g، liblttng-ust1t64، libssl3t64 اور libicu74 کو حاصل کرتا ہے۔ اسکرپٹ ہر لائبریری کے لیے کئی ورژن کے نام آزماتا ہے اور اسے برقرار رکھتا ہے جو آپ کے ریلیز میں موجود ہے، یہی وجہ ہے کہ وہی اسکرپٹ پرانے Ubuntu اور Debian پر بھی کام کرتا ہے۔

اس مرحلے کو چھوڑ دیں تو ./config.sh کچھ بھی کرنے سے پہلے رک جاتا ہے:

Dependencies is missing for Dotnet Core 6.0
Execute sudo ./bin/installdependencies.sh to install any missing Dotnet Core 6.0 dependencies.

libicu کی عدم موجودگی ایک مختلف پہلی لائن، Libicu's dependencies is missing for Dotnet Core 6.0 کے تحت وہی مشورہ دیتی ہے۔ دونوں ایک ہی جگہ سے آتے ہیں: config.sh شروع ہونے سے پہلے بنڈل شدہ لائبریریوں کے خلاف ldd چلاتا ہے، لہذا ایک غیر حل شدہ لنک بعد میں الجھا دینے والے کریش کے بجائے اسکرپٹ کو روک دیتا ہے۔

اپنے ریپوزٹری کے ساتھ رنر کو رجسٹر کریں

ریپوزٹری سے ایک ٹوکن حاصل کریں۔ Settings کھولیں، پھر Actions، پھر Runners، اور پھر New self-hosted runner پر جائیں۔ صفحہ پر ایک رجسٹریشن ٹوکن نظر آئے گا جو A سے شروع ہوتا ہے۔ یہ بننے کے ایک گھنٹے بعد ختم ہو جاتا ہے، لہذا اسے تب ہی بنائیں جب آپ اسے پیسٹ کرنے کے لیے تیار ہوں۔

رنر صارف کے طور پر رجسٹر کریں۔ config.sh کو sudo کے تحت چلانے کی اجازت نہیں ہے۔

sudo -iu gharunner
cd ~/actions-runner
./config.sh --url https://github.com/YOUR-USER/YOUR-REPO \
  --token PASTE_REGISTRATION_TOKEN_HERE \
  --name vps-runner-1 \
  --labels vps \
  --work _work \
  --unattended \
  --replace

یہ فلیگز کیا کام کرتے ہیں۔ --name وہ نام ہے جس سے رنر ریپوزٹری میں ظاہر ہوتا ہے، لہذا ایسا نام منتخب کریں جسے آپ 6 ماہ بعد بھی پہچان سکیں۔ --labels آپ کے اپنے لیبلز کا اضافہ کرتا ہے؛ رنر میں پہلے سے ہی بغیر کسی درخواست کے self-hosted، Linux اور X64 موجود ہوتے ہیں۔ --work اس ڈائریکٹری کا نام متعین کرتا ہے جہاں چیک آؤٹ محفوظ ہوتے ہیں، جو رنر ڈائریکٹری کے اندر ہوتی ہے۔ --unattended انٹرایکٹو پرامپٹس کا جواب ان کی ڈیفالٹ اقدار کے ساتھ دیتا ہے، جو کہ اس وقت ضروری ہوتا ہے جب کمانڈ کسی اسکرپٹ میں موجود ہو۔ --replace ناکام ہونے کے بجائے اسی نام کی موجودہ رجسٹریشن کو اوور رائٹ کر دیتا ہے، جو کہ سرور کو دوبارہ تعمیر کرتے وقت مفید ہوتا ہے۔

ایک کامیاب رن ان لائنوں پر ختم ہوتا ہے:

√ Runner successfully added
√ Runner connection is good
√ Settings Saved.

رجسٹریشن اب رنر ڈائریکٹری میں .runner، .credentials اور .credentials_rsaparams کے طور پر موجود ہے۔ آخری دو فائلیں GitHub پر اس رنر کی شناخت کرتی ہیں، لہذا جو بھی انہیں پڑھ سکتا ہے وہ اس کا روپ دھار سکتا ہے۔ یہی وجہ ہے کہ ڈائریکٹری کا موڈ 700 ہے اور صارف کے پاس sudo کی سہولت نہیں ہے۔

رنر کو بطور systemd سروس انسٹال کریں

ٹرمینل میں ./run.sh ایک ٹیسٹ کے لیے ٹھیک ہے، لیکن آپ کے SSH سیشن کے ختم ہوتے ہی یہ بند ہو جاتا ہے۔ سروس کو انسٹال کریں تاکہ رنر بوٹ کے وقت خود بخود شروع ہو جائے۔ VPS پر systemd سروسز اور ٹائمرز یونٹ فائلز کی وضاحت کرتا ہے۔ یہاں svc.sh آپ کے لیے ایک فائل لکھتا ہے۔

exit
cd /home/gharunner/actions-runner
sudo ./svc.sh install gharunner
sudo ./svc.sh start
sudo ./svc.sh status

svc.sh کے لیے root درکار ہے کیونکہ یہ /etc/systemd/system میں ایک یونٹ لکھتا ہے اور اسے فعال کرتا ہے۔ install کے بعد کا آرگومنٹ وہ صارف ہے جس کے تحت سروس چلتی ہے۔ gharunner کو واضح طور پر پاس کریں۔ کسی آرگومنٹ کے بغیر اسکرپٹ $SUDO_USER پر واپس آ جاتی ہے، جو کہ آپ کا ایڈمن اکاؤنٹ ہے، اور پھر ہر جاب ایک ایسے صارف کے طور پر چلتی ہے جو sudo استعمال کر سکتا ہے۔

یونٹ کا نام ریپوزٹری اور رنر کے نام پر رکھا گیا ہے، جو actions.runner.YOUR-USER-YOUR-REPO.vps-runner-1.service کی شکل میں ہے۔ آپ کو اسے کبھی ٹائپ کرنے کی ضرورت نہیں ہے:

systemctl list-units 'actions.runner.*'
sudo journalctl -u 'actions.runner.*' -n 20 --no-pager

ایک درست رنر √ Connected to GitHub لاگ کرتا ہے اور اس کے بعد ایک لائن جو Listening for Jobs پر ختم ہوتی ہے، اور ریپوزٹری کا Runners صفحہ اسے Idle کے طور پر دکھاتا ہے۔ اگر رنر Offline دکھائے تو اس کا مطلب ہے کہ وہ چل نہیں رہا ہے یا پورٹ 443 پر GitHub تک رسائی حاصل نہیں کر سکتا۔

رنر کو جاب بھیجنا

runs-on لیبل کے ذریعے رنر کا انتخاب کرتا ہے۔ self-hosted کے ساتھ اپنا لیبل شامل کریں، تاکہ جاب کسی ایسے رنر پر نہ جائے جسے آپ نے منتخب نہیں کیا تھا۔

name: build
on:
  push:
    branches: [main]
jobs:
  build:
    runs-on: [self-hosted, linux, vps]
    steps:
      - uses: actions/checkout@v5
      - run: uname -a

اگر جاب Waiting for a runner to pick up this job پر انتظار کر رہی ہے، تو اس کا مطلب ہے کہ لیبلز آپس میں میل نہیں کھاتے۔ runs-on میں موجود ہر لیبل کا رنر پر موجود ہونا ضروری ہے، لہذا ایک اضافی لفظ بھی جاب کو بغیر کسی ایرر کے قطار میں چھوڑ سکتا ہے۔ اس فہرست کا موازنہ ریپوزٹری سیٹنگز میں رنر کے ساتھ دکھائے گئے لیبلز سے کریں۔

خود میزبان رنرز اور عوامی ریپوزٹریز کا ملاپ کیوں خطرناک ہے

یہ وہ حصہ ہے جسے لوگ نظر انداز کر دیتے ہیں۔ GitHub کی ہدایات واضح ہیں: خود میزبان رنرز (self-hosted runners) کو "عوامی ریپوزٹریز کے لیے تقریباً کبھی استعمال نہیں کیا جانا چاہیے"، اور ان میں "عارضی صاف ورچوئل مشینوں پر چلنے کی ضمانت نہیں ہوتی، اور ورک فلو میں موجود غیر معتبر کوڈ کے ذریعے انہیں مستقل طور پر compromised کیا جا سکتا ہے"۔

اس کا طریقہ کار سادہ ہے۔ کسی فورک (fork) سے آنے والی pull request اپنی ورک فلو فائل کی کاپی ساتھ لاتی ہے۔ اگر آپ کی عوامی ریپوزٹری آپ کے رنر پر pull request ورک فلو چلاتی ہے، تو کوئی بھی شخص جو ریپوزٹری کو فورک کر سکتا ہے، وہ ایسا ورک فلو تجویز کر سکتا ہے جو آپ کے VPS پر اس کے کمانڈز چلائے۔ انہیں write access کی ضرورت نہیں ہوتی، کیونکہ جو چیز وہ تجویز کر رہے ہوتے ہیں، وہی چیز رن ہوتی ہے۔

منظوری کی ترتیبات (approval settings) اس مسئلے کو حل کیے بغیر کچھ حد تک کم کر دیتی ہیں۔ عوامی ریپوزٹری کے لیے ڈیفالٹ پالیسی یہ ہے کہ مینٹینر سے پہلی بار حصہ لینے والے کے فورک ورک فلو کو منظور کرنے کا کہا جاتا ہے۔ ایک بار جب آپ اس شخص کو منظور کر لیتے ہیں، تو ان کی بعد کی pull requests بغیر کسی نئی پرامپٹ کے چل جاتی ہیں۔ لہذا، رکاوٹ ہر بار ایک انسان کا diff پڑھنا ہے، اور بلڈ اسکرپٹ میں تین درجے نیچے چھپا ہوا پے لوڈ (payload) نظر انداز کرنا آسان ہے۔

فورک pull request کو آپ کے secrets نہیں ملتے، اور اس کا GITHUB_TOKEN صرف پڑھنے کے لیے (read only) ہوتا ہے۔ یہ GitHub کے اندر نقصان کو محدود کرتا ہے۔ لیکن یہ آپ کے سرور کے لیے کچھ نہیں کرتا۔ حملہ آور کے پاس gharunner کے طور پر شیل (shell) ہوتا ہے، لہذا وہ ہر اس فائل کو پڑھ سکتا ہے جسے وہ صارف پڑھ سکتا ہے، اپنے نجی نیٹ ورک پر VPS کی پہنچ میں موجود ہر چیز تک رسائی حاصل کر سکتا ہے، اور ~/.bashrc یا صارف کی systemd یونٹ میں کچھ ایسا چھوڑ سکتا ہے جو اگلی جاب کے دوران چلے۔

--ephemeral کے ساتھ رجسٹر کرنے سے رنر ایک جاب قبول کرتا ہے اور پھر deregister ہو جاتا ہے، لہذا ایک جاب اگلی جاب کے ورک اسپیس کو نہیں پڑھ سکتی۔ یہ صرف تب مددگار ہوتا ہے اگر کوئی چیز ہر جاب کے لیے مشین یا کنٹینر کو دوبارہ تعمیر (rebuild) کرے، کیونکہ رنر صارف کی ہوم ڈائریکٹری میں لکھا گیا بیک ڈور (backdoor) ایک نئی رجسٹریشن کے بعد بھی برقرار رہتا ہے۔

ذیل میں دیے گئے اصول مختصر ہیں۔ خود میزبان رنرز کو نجی ریپوزٹریز کے لیے استعمال کریں۔ اگر آپ کو اسے کسی عوامی ریپوزٹری سے منسلک کرنا ہی ہے، تو اس پر فورک pull requests نہ چلائیں، اس سرور پر کچھ اور نہ رکھیں، اور مشین کو قابلِ تلف (disposable) سمجھیں۔

Docker ملازمتیں، اور وہ گروپ جو درحقیقت root ہے

کنٹینر ملازمتیں، سروس کنٹینرز اور کوئی بھی ورک فلو مرحلہ جو docker build کو کال کرتا ہے، اسے رنر ہوسٹ پر Docker ڈیمن کی ضرورت ہوتی ہے۔ Docker کو معمول کے مطابق انسٹال کریں، جس کا احاطہ VPS پر Docker اور Docker Compose میں کیا گیا ہے، پھر رنر صارف کو docker گروپ میں شامل کریں۔

اس اقدام سے پہلے اس کے نقصانات کو سمجھ لیں۔ docker گروپ کی رکنیت root کے مساوی ہے، کیونکہ ایک کنٹینر / کو بائنڈ ماؤنٹ کر سکتا ہے اور اس کے اندر root کے طور پر چل سکتا ہے۔ لہذا، ایک ورک فلو جو Docker ساکٹ سے بات کر سکتا ہے، وہ VPS پر موجود ہر فائل کو پڑھ اور لکھ سکتا ہے، بشمول /etc/shadow۔ ایک نجی ریپوزٹری پر جہاں قابل اعتماد معاونین موجود ہوں، یہ ایک قابل قبول قیمت ہو سکتی ہے۔ کسی بھی دوسری جگہ، یہ غیر مراعات یافتہ صارف کے مقصد کو ختم کر دیتا ہے۔ Rootless Docker کنٹینر بلڈز کو رنر صارف کے اپنے حقوق کے اندر رکھتا ہے، جس کی قیمت ایک سست اسٹوریج ڈرائیور اور مراعات یافتہ کنٹینرز کا نہ ہونا ہے۔

اپ ڈیٹس، اور رنر کو مکمل طور پر ہٹانا

ایک سیلف ہوسٹڈ رنر بائی ڈیفالٹ خود کو اپ ڈیٹ کرتا ہے۔ یہ ایک نئی ریلیز کی نشاندہی کرتا ہے، اپنی فائلیں تبدیل کرتا ہے اور سروس کو دوبارہ شروع کرتا ہے، لہذا عام طور پر آپ کو کچھ کرنے کی ضرورت نہیں ہوتی۔ ./config.sh --disableupdate سیلف اپ ڈیٹ کو اس وقت بند کر دیتا ہے جب آپ کو ایک فکسڈ ورژن درکار ہو۔ اس کے بعد، اپ ڈیٹ کرنا آپ کی ذمہ داری ہے: GitHub کی دستاویزات واضح کرتی ہیں کہ --disableupdate کے ساتھ کنفیگر کیے گئے رنر کو دستی طور پر اپ ڈیٹ کرنا پڑتا ہے۔

دستی اپ ڈیٹ رجسٹریشن کو برقرار رکھتا ہے، کیونکہ .runner اور .credentials ٹار بال (tarball) میں نہیں ہوتے ہیں۔ سروس کو روکیں، نئے ٹار بال کو gharunner کے طور پر ڈاؤن لوڈ اور چیک سم کریں، اسے tar xzf کے ساتھ اسی ڈائریکٹری پر ایکسٹریکٹ کریں، پھر سروس کو دوبارہ شروع کریں:

cd /home/gharunner/actions-runner
sudo ./svc.sh stop
sudo ./svc.sh start

رنر کو ہٹانے کے لیے، پہلے سروس کو ان انسٹال کریں، پھر ڈی رجسٹر کریں۔ ریموول ٹوکن اسی Runners صفحہ سے، رنر کے اپنے Remove بٹن کے نیچے سے حاصل ہوتا ہے۔

cd /home/gharunner/actions-runner
sudo ./svc.sh stop
sudo ./svc.sh uninstall
sudo -iu gharunner
cd ~/actions-runner
./config.sh remove --token PASTE_REMOVAL_TOKEN_HERE

ڈی رجسٹر کیے بغیر ڈائریکٹری کو حذف کرنے سے رنر ریپوزٹری میں Offline کے طور پر درج رہتا ہے، کیونکہ GitHub کو صرف تب پتہ چلتا ہے کہ یہ ختم ہو گیا ہے جب رنر خود بتاتا ہے یا کوئی ایڈمن دستی طور پر اندراج کو حذف کرتا ہے۔

ناکامی کے موڈز، ان اسٹرنگز کے ساتھ جو آپ دیکھیں گے

Must not run with sudo۔ جب config.sh کو root کے طور پر چلایا جاتا ہے تو یہ اسٹرنگ پرنٹ کرتا ہے اور ایگزٹ ہو جاتا ہے۔ یہ چیک جان بوجھ کر رکھا گیا ہے، کیونکہ _work میں root کی ملکیت والی فائلیں ہر اس بعد والے کام کو خراب کر دیتی ہیں جو سروس یوزر کے طور پر چلتا ہے۔ ./config.sh کو gharunner کے طور پر چلائیں۔ RUNNER_ALLOW_RUNASROOT ویری ایبل اس چیک کو اوور رائیڈ کر دیتا ہے، اور اسے استعمال کرنے سے خرابی صرف بعد کے مراحل پر منتقل ہو جاتی ہے۔

sudo: ./svc.sh: command not found۔ آپ درست ڈائریکٹری میں ہیں۔ svc.sh ابھی موجود نہیں ہے، کیونکہ config.sh نے رجسٹریشن مکمل نہیں کی ہے۔ رنر (runner) کو رجسٹر کریں، پھر سروس انسٹال کریں۔

Http response code: NotFound from 'POST https://api.github.com/actions/runner-registration'۔ ٹوکن ایک درست رجسٹریشن ٹوکن نہیں ہے۔ یا تو اس کی میعاد ختم ہو چکی ہے، کیونکہ یہ ایک گھنٹے تک کارآمد رہتے ہیں، یا Runners کے صفحے سے رجسٹریشن ٹوکن کی جگہ پرسنل ایکسس ٹوکن پیسٹ کر دیا گیا ہے۔ ایک نیا ٹوکن جنریٹ کریں اور اسے دوبارہ پیسٹ کریں۔

Dependencies is missing for Dotnet Core 6.0۔ رنر ڈائریکٹری سے sudo ./bin/installdependencies.sh کو root کے طور پر چلائیں، پھر دوبارہ رجسٹر کریں۔

ری بوٹ کے بعد رنر آف لائن ہونا۔ systemctl is-enabled 'actions.runner.*' چلائیں۔ اگر کچھ بھی لسٹ نہیں ہوتا ہے، تو ./svc.sh install کبھی نہیں چلایا گیا تھا، لہذا رنر صرف آپ کے ٹرمینل سیشن کے اندر ہی موجود تھا۔ اگر یونٹ فعال (enabled) ہے اور رنر اب بھی Offline ہے، تو journalctl -u 'actions.runner.*' پڑھیں اور آؤٹ باؤنڈ HTTPS کو چیک کریں۔

ڈسک کا بھر جانا۔ چیک آؤٹس، بلڈ کیشے اور Docker امیجز _work کے تحت اور رنر یوزر کی ہوم ڈائریکٹری میں جمع ہوتے رہتے ہیں، اور کوئی بھی چیز انہیں آپ کے لیے صاف نہیں کرتی ہے۔ du -sh /home/gharunner/actions-runner/_work کو مانیٹر کریں اور ڈسک کے خود فیصلہ کرنے سے پہلے ایک شیڈولڈ کلین اپ شامل کریں۔

FAQ

sudo ./svc.sh install command not found کیوں کہتا ہے؟

اس کی وجہ یہ ہے کہ svc.sh رنر ٹار بال (runner tarball) میں موجود نہیں ہوتا۔ یہ اس وقت رنر ڈائریکٹری میں تخلیق ہوتا ہے جب ./config.sh رجسٹریشن مکمل کر لیتا ہے، اور یہ آپ کی ریپوزٹری اور رنر کے نام کو استعمال کرتے ہوئے سروس کا نام بناتا ہے۔ پہلے ./config.sh کو رنر صارف کے طور پر چلائیں۔ اس کے بعد، sudo ./svc.sh install gharunner اسکرپٹ کو تلاش کر لیتا ہے اور actions.runner.OWNER-REPO.RUNNER-NAME.service نام کی ایک یونٹ فائل کو /etc/systemd/system میں لکھ دیتا ہے۔

کیا مجھے سیلف ہوسٹڈ رنر کے لیے فائر وال پورٹ کھولنے کی ضرورت ہے؟

نہیں۔ رنر GitHub کے ساتھ ایک آؤٹ باؤنڈ HTTPS کنکشن کھولتا ہے اور جابز کا انتظار کرتے ہوئے اسے کھلا رکھتا ہے، لہذا GitHub کبھی بھی آپ کے VPS سے کنکشن شروع نہیں کرتا۔ آؤٹ باؤنڈ 443 کی اجازت دیں اور اپنے ان باؤنڈ رولز کو بند رکھیں۔ اگر رنر سروس چلنے کے دوران Offline دکھاتا ہے، تو ان باؤنڈ رولز کے بجائے آؤٹ باؤنڈ فلٹرنگ اور DNS کو چیک کریں۔

کیا میں پبلک ریپوزٹری پر سیلف ہوسٹڈ رنر استعمال کر سکتا ہوں؟

آپ کر سکتے ہیں، لیکن GitHub اس کا مشورہ نہیں دیتا۔ فورک (fork) سے آنے والی پل ریکویسٹ (pull request) اپنی ورک فلو فائل ساتھ لاتی ہے، لہذا کوئی بھی شخص جو آپ کی ریپوزٹری کو فورک کر سکتا ہے، وہ ایسے کمانڈز تجویز کر سکتا ہے جو آپ کی مشین پر چلیں۔ منظوری کا پرامپٹ صرف ایک کنٹریبیوٹر کی پہلی رن کا احاطہ کرتا ہے۔ اگر آپ کسی پبلک ریپوزٹری کے ساتھ رنر منسلک کرتے ہیں، تو اس پر فورک پل ریکویسٹ ورک فلو کو غیر فعال کر دیں، اس سرور پر کچھ اور نہ رکھیں، اور ایک شیڈول کے مطابق مشین کو دوبارہ تعمیر (rebuild) کریں۔

رجسٹریشن Http response code: NotFound کے ساتھ کیوں ناکام ہوتی ہے؟

رجسٹریشن کال اس وقت NotFound کا جواب دیتی ہے جب اسناد (credentials) غلط ہوں، نہ صرف تب جب URL غلط ہو، جس کی وجہ سے یہ پیغام گمراہ کن ہو جاتا ہے۔ رجسٹریشن ٹوکن دکھائے جانے کے ایک گھنٹے بعد ختم ہو جاتے ہیں، اور اس کال کے لیے پرسنل ایکسس ٹوکن قبول نہیں کیا جاتا۔ Settings، Actions، Runners، اور پھر New self-hosted runner کو دوبارہ کھولیں، نیا ٹوکن کاپی کریں، اور تصدیق کریں کہ --url کی ویلیو ایسی ریپوزٹری کی طرف اشارہ کر رہی ہے جہاں آپ کے پاس ایڈمن کے حقوق موجود ہیں۔