Ubuntu 24.04 पर GitHub Actions runner कैसे सेटअप करें

Self-hosted GitHub Actions runner क्या करता है

Self-hosted GitHub Actions runner एक ऐसा प्रोग्राम है जिसे आप अपने VPS पर इंस्टॉल करते हैं। यह GitHub से jobs मांगता है और उन्हें आपके हार्डवेयर पर चलाता है। आप इसे एक repository के साथ रजिस्टर करते हैं, इसे systemd service के रूप में इंस्टॉल करते हैं, और यह हर reboot के बाद अपने आप चालू हो जाता है। GitHub job को schedule करता है, जबकि आपका सर्वर काम पूरा करता है।

अपने खुद के सर्वर पर CI (continuous integration) का उपयोग करने के दो मुख्य लाभ हैं। Build minutes की गणना बंद हो जाती है, और job उन संसाधनों तक पहुँच सकती है जो केवल आपकी मशीन पर उपलब्ध हैं, जैसे कि warm build cache या private network। इसकी कीमत सुरक्षा है। Runner workflow file में दिए गए निर्देशों को उसी user के रूप में निष्पादित करता है जिसे आपने अनुमति दी है, इसलिए workflow file का अर्थ ही remote code execution है। Private repository पर, केवल उन्हीं लोगों पर भरोसा किया जाना चाहिए जिन्हें workflow चलाने की अनुमति है, जिसमें वे लोग भी शामिल हैं जो fork pull requests सबमिट कर सकते हैं जो runner पर चलते हैं। Public repository पर यह एक वास्तविक जोखिम है, और fork pull requests वाला अनुभाग इसके तंत्र को स्पष्ट करता है।

नीचे दी गई सभी जानकारी Ubuntu 24.04 और runner version 2.338.0 के लिए है, जो 12 October 2026 तक का वर्तमान release है। GitHub का नवीनतम release 4 November 2026 तक 2.338.2 है; नीचे दिए गए commands और checksum 2.338.0 पर ही आधारित हैं।

शुरू करने से पहले आपको क्या चाहिए

एक ऐसे VPS से शुरुआत करें जिसमें एक सामान्य एडमिन अकाउंट और sudo एक्सेस हो, जो नए VPS पर शुरुआती दस मिनट में प्राप्त की गई स्थिति के समान हो। आपको किसी इनबाउंड पोर्ट को खोलने की आवश्यकता नहीं है। रनर GitHub के साथ एक आउटबाउंड HTTPS (हाइपरटेक्स्ट ट्रांसफर प्रोटोकॉल सिक्योर) कनेक्शन खोलता है और काम की प्रतीक्षा करते समय इसे खुला रखता है, इसलिए GitHub कभी भी आपके सर्वर से कनेक्ट नहीं होता है। आपका फायरवॉल बाहरी दुनिया के लिए बंद रह सकता है और जॉब्स फिर भी प्राप्त होती रहेंगी।

आपको रिपॉजिटरी पर एडमिन अधिकारों की भी आवश्यकता है, क्योंकि रजिस्ट्रेशन टोकन रिपॉजिटरी सेटिंग्स में दिखाया जाता है।

रनर के लिए एक समर्पित यूजर बनाएँ

रनर को कभी भी root के रूप में या अपने स्वयं के एडमिन यूजर के रूप में न चलाएँ। प्रत्येक जॉब रनर यूजर के अधिकारों को इनहेरिट करती है, इसलिए यदि रनर यूजर sudo का उपयोग कर सकता है, तो sudo को कॉल करने वाला वर्कफ़्लो सफल हो जाता है। एक ऐसा अनप्रिविलेज्ड यूजर बनाएँ जिसके पास अपनी होम डायरेक्टरी के अलावा कुछ भी न हो। 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 महत्वपूर्ण है क्योंकि रनर अपने क्रेडेंशियल्स को वहाँ प्लेनटेक्स्ट में स्टोर करता है, और चेकआउट में प्राइवेट सोर्स हो सकता है।

आगे बढ़ने से पहले दोनों गुणों की जाँच करें:

sudo passwd -S gharunner
sudo -l -U gharunner

passwd -S एक लाइन प्रिंट करता है जो gharunner L से शुरू होती है, जहाँ L का अर्थ है कि पासवर्ड लॉक है। sudo -l -U gharunner को is not allowed to run sudo के साथ उत्तर देना चाहिए। यदि यह इसके बजाय अनुमत कमांड की एक सूची प्रिंट करता है, तो अकाउंट sudo ग्रुप में है और जो आइसोलेशन आपने अभी बनाया है वह समाप्त हो गया है।

Runner डाउनलोड करें और tarball की जाँच करें

यहाँ से runner user के रूप में कार्य करें।

sudo -iu gharunner
cd ~/actions-runner
RUNNER_VERSION=2.338.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"

यदि आप architecture के बारे में सुनिश्चित नहीं हैं, तो पहले uname -m चलाएँ। x86_64 ऊपर दी गई linux-x64 फ़ाइल का उपयोग करता है। aarch64, actions-runner-linux-arm64-${RUNNER_VERSION}.tar.gz का उपयोग करता है।

अब सत्यापित करें कि आपने क्या डाउनलोड किया है। नीचे दिया गया SHA256 (secure hash algorithm, 256 bit) 2.338.0 x64 tarball के लिए है। GitHub वर्तमान release के लिए मान को release page पर और New self-hosted runner स्क्रीन पर दिखाता है। यह हर version के साथ बदलता है, इसलिए जब आप कोई अलग version install करें तो इसे वहीं से कॉपी करें।

echo "af4b794c1bc41d73d40535e3fe092a39f9679cd8d965954c2aca25a05ca41d32  actions-runner-linux-x64-2.338.0.tar.gz" | sha256sum -c

एक सफल डाउनलोड एक पंक्ति प्रिंट करता है:

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

एक अधूरी या बदली हुई फ़ाइल विफलता और चेतावनी प्रिंट करती है:

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

जाँच को छोड़ें नहीं और tar को समस्या ढूँढने न दें। एक आधी-अधूरी archive gzip: stdin: unexpected end of file और tar: Unexpected EOF in archive के साथ विफल हो जाती है, जो आपको यह तो बताती है कि फ़ाइल खराब है, लेकिन यह नहीं बताती कि क्या वह बीच में कट गई थी या उसे बदल दिया गया था।

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

tarball में क्या शामिल है, और क्या नहीं

एक्सट्रैक्शन के बाद डायरेक्टरी में config.sh, run.sh, env.sh, safe_sleep.sh, bin/ और externals/ मौजूद होते हैं। bin/ में रनर बाइनरी और bin/installdependencies.sh होते हैं। externals/ में बंडल किया गया Node रनटाइम होता है जिस पर JavaScript एक्शन निष्पादित (execute) होते हैं।

अभी तक कोई svc.sh मौजूद नहीं है। GitHub का डॉक्यूमेंटेशन इसे उस स्क्रिप्ट के रूप में वर्णित करता है "जो रनर को सफलतापूर्वक जोड़ने के बाद बनाई जाती है", क्योंकि इसे एक टेम्प्लेट से लिखा जाता है जिसमें आपकी रिपॉजिटरी और रनर का नाम सर्विस नाम के रूप में शामिल होता है। इसलिए ./config.sh से पहले sudo ./svc.sh install चलाने पर sudo: ./svc.sh: command not found के साथ विफलता मिलती है। पहले रजिस्टर करें, फिर सर्विस इंस्टॉल करें।

Runner dependencies इंस्टॉल करें

Runner एक .NET application है, इसलिए इसे कुछ shared libraries की आवश्यकता होती है। Runner user के shell से बाहर निकलें और उन्हें sudo के साथ इंस्टॉल करें, क्योंकि script system package database में लिखती है।

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

Ubuntu 24.04 पर यह libkrb5-3, zlib1g, liblttng-ust1t64, libssl3t64 और libicu74 को pull करता है। Script प्रत्येक library के लिए कई version names का प्रयास करती है और उस version को रखती है जिसे आपका release प्रदान करता है, यही कारण है कि वही script पुराने Ubuntu और Debian पर भी काम करती है।

यदि ldd के साथ जाँची गई कोई library गायब है, तो ./config.sh runner को शुरू करने से पहले रुक जाता है:

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 के साथ bundled libraries की जाँच करता है, और libicu, ldconfig के साथ जाँच करता है, इसलिए एक unresolved link बाद में भ्रमित करने वाले crash के बजाय script को रोक देता है। ये जाँचें उन सभी packages को कवर नहीं करती हैं जिन्हें installer सूचीबद्ध करता है। गायब liblttng-ust1t64 उन्हें trigger नहीं करता है: .NET LTTng tracing को वैकल्पिक रूप से load करता है और जब इसकी tracing dependencies अनुपलब्ध होती हैं तो यह जारी रहता है।

अपने रिपॉजिटरी के साथ रनर को रजिस्टर करें

रिपॉजिटरी से एक टोकन प्राप्त करें। Settings खोलें, फिर Actions, फिर Runners, और उसके बाद New self-hosted runner पर जाएं। पेज पर एक रजिस्ट्रेशन टोकन दिखाई देगा। यह बनने के एक घंटे बाद एक्सपायर हो जाता है, इसलिए इसे तभी जनरेट करें जब आप इसे पेस्ट करने के लिए तैयार हों।

रनर यूजर के रूप में रजिस्टर करें। 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 वह नाम है जिससे रनर रिपॉजिटरी में दिखाई देता है, इसलिए ऐसा नाम चुनें जिसे आप छह महीने बाद भी पहचान सकें। --labels आपके अपने लेबल्स जोड़ता है; रनर में पहले से ही बिना मांगे self-hosted, Linux और X64 मौजूद होते हैं। --work उस डायरेक्टरी का नाम बताता है जहाँ चेकआउट्स स्टोर होते हैं, जो रनर डायरेक्टरी के अंदर होती है। --unattended इंटरैक्टिव प्रॉम्प्ट्स का उत्तर उनके डिफॉल्ट्स के साथ देता है, जो तब उपयोगी होता है जब कमांड किसी स्क्रिप्ट में चल रही हो। --replace फेल होने के बजाय उसी नाम के मौजूदा रजिस्ट्रेशन को ओवरराइड कर देता है, जो सर्वर को फिर से बनाते समय आवश्यक होता है।

एक सफल रन इन लाइनों के साथ समाप्त होता है:

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

रजिस्ट्रेशन अब रनर डायरेक्टरी में .runner, .credentials और .credentials_rsaparams के रूप में मौजूद है। अंतिम दो फाइलें इस रनर की पहचान GitHub के लिए करती हैं, इसलिए जो कोई भी इन्हें पढ़ सकता है, वह इसका प्रतिरूपण (impersonate) कर सकता है। यही कारण है कि डायरेक्टरी का मोड 700 है और यूजर के पास sudo एक्सेस नहीं है।

runner को systemd सर्विस के रूप में इंस्टॉल करें

./run.sh को टर्मिनल में चलाना एक टेस्ट के लिए ठीक है, लेकिन SSH सेशन बंद होते ही यह बंद हो जाता है। सर्विस को इंस्टॉल करें ताकि runner बूट होने पर अपने आप शुरू हो जाए। 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 का उपयोग कर सकता है।

यूनिट का नाम रिपॉजिटरी और runner के आधार पर actions.runner.YOUR-USER-YOUR-REPO.vps-runner-1.service के रूप में रखा गया है। आपको इसे कभी भी टाइप करने की आवश्यकता नहीं है:

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

एक सही ढंग से काम कर रहा runner √ Connected to GitHub लॉग करता है और उसके बाद एक लाइन आती है जो Listening for Jobs पर समाप्त होती है, और रिपॉजिटरी का Runners पेज इसे Idle के रूप में दिखाता है। यदि runner Offline दिखाई देता है, तो इसका मतलब है कि या तो वह चल नहीं रहा है या वह पोर्ट 443 पर GitHub तक नहीं पहुँच पा रहा है।

Runner को job भेजें

runs-on label के आधार पर runner का चयन करता है। self-hosted के साथ अपना स्वयं का label जोड़ें, ताकि job किसी ऐसे runner पर न जाए जिसे आप लक्षित नहीं कर रहे थे।

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

यदि job Waiting for a runner to pick up this job पर प्रतीक्षा कर रही है, तो जाँचें कि क्या कोई matching runner online और idle है। runs-on में मौजूद प्रत्येक label का runner पर होना अनिवार्य है, इसलिए एक भी अतिरिक्त शब्द होने पर job तब तक queued रहेगी जब तक कि कोई matching runner उपलब्ध न हो जाए या 24 घंटे बाद job fail न हो जाए। repository settings में runner के बगल में दिखाए गए labels की सूची के साथ अपनी सूची का मिलान करें।

क्यों self-hosted runners और public repositories का मेल सही नहीं है

यह वह हिस्सा है जिसे लोग छोड़ देते हैं। GitHub का मार्गदर्शन स्पष्ट है: self-hosted runners का उपयोग "public repositories के लिए लगभग कभी नहीं किया जाना चाहिए", और "इनकी ephemeral clean virtual machines पर चलने की कोई गारंटी नहीं होती है, और इन्हें workflow में मौजूद untrusted code द्वारा स्थायी रूप से compromised किया जा सकता है"।

इसकी प्रक्रिया सरल है। Fork से आया एक pull request अपने साथ workflow file की अपनी प्रति लाता है। यदि आपकी public repository आपके runner पर pull request workflows चलाती है, तो कोई भी व्यक्ति जो repository को fork कर सकता है, वह ऐसा workflow प्रस्तावित कर सकता है जो आपके VPS पर उनके commands चलाए। उन्हें write access की आवश्यकता नहीं है, क्योंकि जो वे प्रस्तावित कर रहे हैं वही वह चीज़ है जो run होती है।

Approval settings इसे ठीक किए बिना थोड़ा कम जोखिम भरा बनाती हैं। Public repository के लिए default policy एक maintainer से first-time contributor के fork workflow को approve करने के लिए कहती है। GitHub किसी को केवल तब तक first-time मानता है जब तक कि उनका कोई commit या pull request repository में merge न हो जाए। उसके बाद, उनके बाद के pull requests बिना किसी prompt के run होते हैं, और GitHub स्वयं चेतावनी देता है कि एक छोटा सा merged fix वहां तक पहुँचने के लिए पर्याप्त है। इसलिए यह बाधा एक इंसान द्वारा diff पढ़ने पर निर्भर है, और build script में तीन स्तर नीचे छिपाया गया payload आसानी से अनदेखा किया जा सकता है।

Fork pull request को आपके secrets प्राप्त नहीं होते हैं, और इसका GITHUB_TOKEN read-only होता है। यह GitHub के भीतर नुकसान को सीमित करता है। यह आपके सर्वर के लिए कुछ नहीं करता है। हमलावर के पास gharunner के रूप में shell होता है, इसलिए वे हर उस file को पढ़ सकते हैं जिसे वह user पढ़ सकता है, उस हर चीज़ तक पहुँच सकते हैं जिसे VPS अपने private network पर access कर सकता है, और ~/.bashrc या user systemd unit में कुछ ऐसा छोड़ सकते हैं जो अगले job के दौरान run हो।

--ephemeral के साथ register करने पर runner एक job स्वीकार करता है और फिर deregister हो जाता है; यह उस job के workspace को मिटाता नहीं है। यह केवल तभी मदद करता है यदि कोई चीज़ प्रत्येक job के लिए machine या container को rebuild करे, क्योंकि runner user की home directory में लिखा गया backdoor एक fresh registration के बाद भी बना रहता है।

नीचे दिए गए नियम संक्षिप्त हैं। Self-hosted runners का उपयोग private repositories के लिए करें। यदि आपको इसे किसी public repository से जोड़ना ही है, तो उस पर fork pull requests न चलाएं, उस सर्वर पर कुछ और न रखें, और machine को disposable मानें।

Docker jobs, और वह group जो वास्तव में root है

Container jobs, service containers और कोई भी workflow step जो docker build को call करता है, उसे runner host पर Docker daemon की आवश्यकता होती है। Docker को सामान्य तरीके से install करें, जिसे Docker and Docker Compose on a VPS में समझाया गया है, फिर runner user को docker group में जोड़ें।

ऐसा करने से पहले इसके परिणामों को समझें। docker group की सदस्यता root के बराबर है, क्योंकि एक container / को bind mount कर सकता है और उसके अंदर root के रूप में चल सकता है। इसलिए, जो workflow Docker socket से बात कर सकता है, वह VPS की हर file को पढ़ और लिख सकता है, जिसमें /etc/shadow भी शामिल है। एक private repository पर जहाँ trusted contributors हों, यह एक स्वीकार्य समझौता हो सकता है। अन्य किसी भी स्थिति में, यह unprivileged user रखने के उद्देश्य को ही खत्म कर देता है। Rootless Docker container builds को runner user के अपने अधिकारों के भीतर रखता है, जिसमें storage driver और networking की सीमाएँ होती हैं; container capabilities host पर विशेषाधिकार प्रदान नहीं करती हैं।

अपडेट और रनर को पूरी तरह से हटाना

एक self-hosted runner डिफ़ॉल्ट रूप से खुद को अपडेट कर लेता है। यह एक नए release का पता लगाता है, अपनी फाइलों को बदलता है और service को restart कर देता है, इसलिए सामान्यतः आपको कुछ करने की आवश्यकता नहीं होती। self-update को बंद करने के लिए, runner को register करते समय --disableupdate को ./config.sh के साथ पास करें; पहले से register किए गए runner पर, इसका मतलब है कि flag के साथ इसे फिर से register करना होगा। यह आपको हमेशा के लिए एक ही version पर बने रहने की अनुमति नहीं देता है। GitHub का documentation स्पष्ट है कि --disableupdate के साथ configure किए गए runner को भी नए release के 30 दिनों के भीतर हाथ से अपडेट करना होगा, अन्यथा GitHub उस पर jobs की queue बनाना बंद कर देगा। एक critical security update उस समय सीमा की प्रतीक्षा किए बिना, jobs को queue होने से रोक सकता है जब तक कि आप अपडेट न कर लें।

Manual अपडेट करने पर registration बना रहता है, क्योंकि .runner और .credentials tarball में नहीं होते हैं। service को stop करें, नए tarball को gharunner के रूप में download करें और checksum verify करें, इसे tar xzf के साथ उसी directory में extract करें, और फिर service को फिर से start करें:

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

रनर को हटाने के लिए, पहले service को uninstall करें, फिर deregister करें। removal token उसी Runners page से मिलता है, जो runner के अपने 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

deregister किए बिना directory को delete करने से runner repository में Offline के रूप में सूचीबद्ध रहता है। यह तब तक वहां रहता है जब तक कोई admin Force remove this runner पर क्लिक नहीं करता, या जब तक GitHub इसे 14 दिनों तक connection न होने पर स्वचालित रूप से नहीं हटा देता।

विफलता के प्रकार और वे संदेश जो आपको दिखाई देंगे

Must not run with sudo। जब config.sh को root के रूप में चलाया जाता है, तो यह संदेश दिखाई देता है और प्रोग्राम बंद हो जाता है। यह जाँच जानबूझकर की गई है, क्योंकि _work में root के स्वामित्व वाली फाइलें बाद में service user के रूप में चलने वाले हर कार्य को बाधित कर देती हैं। ./config.sh को gharunner के रूप में चलाएं। RUNNER_ALLOW_RUNASROOT वेरिएबल इस जाँच को अनदेखा कर देता है, लेकिन इसका उपयोग करने से समस्या केवल बाद के लिए टल जाती है।

sudo: ./svc.sh: command not found। आप सही निर्देशिका (directory) में हैं। svc.sh अभी मौजूद नहीं है, क्योंकि config.sh ने पंजीकरण (registration) पूरा नहीं किया है। runner को रजिस्टर करें, फिर service को install करें।

Http response code: NotFound from 'POST https://api.github.com/actions/runner-registration'। आमतौर पर यह टोकन एक वैध पंजीकरण टोकन नहीं होता है। या तो इसकी समय सीमा समाप्त हो गई है, क्योंकि ये केवल एक घंटे के लिए मान्य होते हैं, या Runners पेज से पंजीकरण टोकन के स्थान पर personal access token पेस्ट कर दिया गया है। एक नया टोकन जनरेट करें और उसे फिर से पेस्ट करें, और जाँचें कि --url पूरा repository URL है।

Dependencies is missing for Dotnet Core 6.0। runner निर्देशिका से root के रूप में sudo ./bin/installdependencies.sh चलाएं, फिर दोबारा रजिस्टर करें।

Reboot के बाद Runner का Offline होना। systemctl is-enabled 'actions.runner.*' चलाएं। यदि सूची में कुछ भी नहीं दिखता है, तो ./svc.sh install कभी नहीं चलाया गया था, जिसका अर्थ है कि runner केवल आपके terminal session के भीतर ही मौजूद था। यदि unit enabled है और runner अभी भी Offline है, तो journalctl -u 'actions.runner.*' पढ़ें और outbound HTTPS की जाँच करें।

डिस्क का भर जाना। Checkouts, build caches और Docker images _work के अंतर्गत और runner user की home directory में जमा हो जाते हैं, और कोई भी उन्हें आपके लिए साफ (prune) नहीं करता है। du -sh /home/gharunner/actions-runner/_work पर नज़र रखें और डिस्क के भर जाने से पहले एक scheduled clean-up जोड़ें।

FAQ

sudo ./svc.sh install 'command not found' क्यों कहता है?

क्योंकि svc.sh रनर टारबॉल (runner tarball) में शामिल नहीं होता है। यह रनर डायरेक्टरी में तब जनरेट होता है जब ./config.sh रजिस्ट्रेशन पूरा कर लेता है, जो आपके रिपॉजिटरी और रनर नाम का उपयोग करके सर्विस का नाम बनाता है। सबसे पहले रनर यूजर के रूप में ./config.sh चलाएं। उसके बाद, sudo ./svc.sh install gharunner स्क्रिप्ट को ढूंढ लेता है और /etc/systemd/system में actions.runner.OWNER-REPO.RUNNER-NAME.service नाम की एक यूनिट लिख देता है।

क्या मुझे self-hosted runner के लिए फायरवॉल पोर्ट खोलने की आवश्यकता है?

नहीं। रनर GitHub के साथ एक आउटबाउंड HTTPS कनेक्शन खोलता है और जॉब्स का इंतजार करते समय उसे खुला रखता है, इसलिए GitHub कभी भी आपके VPS से कनेक्शन शुरू नहीं करता है। आउटबाउंड 443 को अनुमति दें और अपने इनबाउंड रूल्स को बंद रखें। यदि सर्विस चलने के दौरान रनर 'Offline' दिखाता है, तो इनबाउंड रूल्स के बजाय आउटबाउंड फिल्टरिंग और DNS की जाँच करें।

क्या मैं पब्लिक रिपॉजिटरी पर self-hosted runner का उपयोग कर सकता हूँ?

आप ऐसा कर सकते हैं, लेकिन GitHub इसकी सलाह नहीं देता है। फोर्क (fork) से आने वाले पुल रिक्वेस्ट में अपनी खुद की वर्कफ़्लो फ़ाइल होती है, इसलिए कोई भी व्यक्ति जो आपकी रिपॉजिटरी को फोर्क कर सकता है, वह ऐसे कमांड प्रस्तावित कर सकता है जो आपकी मशीन पर चलते हैं। डिफ़ॉल्ट अप्रूवल प्रॉम्प्ट केवल उन योगदानकर्ताओं को कवर करता है जिनका कोई कमिट या पुल रिक्वेस्ट रिपॉजिटरी में मर्ज नहीं हुआ है। यदि आप किसी पब्लिक रिपॉजिटरी से रनर जोड़ते हैं, तो उस पर 'fork pull request workflows' को डिसेबल कर दें, उस सर्वर पर कुछ और न रखें, और समय-समय पर मशीन को रीबिल्ड करते रहें।

Http response code: NotFound के साथ रजिस्ट्रेशन विफल क्यों होता है?

रजिस्ट्रेशन कॉल 'NotFound' का उत्तर तब देती है जब क्रेडेंशियल गलत होते हैं, न कि केवल तब जब URL गलत हो, जिससे यह संदेश भ्रामक हो जाता है। रजिस्ट्रेशन टोकन दिखाए जाने के एक घंटे बाद समाप्त हो जाते हैं, और इस कॉल के लिए पर्सनल एक्सेस टोकन स्वीकार नहीं किया जाता है। Settings, Actions, Runners, New self-hosted runner को फिर से खोलें, नया टोकन कॉपी करें, और पुष्टि करें कि --url वैल्यू उस रिपॉजिटरी की ओर इशारा करती है जहाँ आपके पास एडमिन अधिकार हैं।