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

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

self-hosted GitHub Actions runner एक ऐसा प्रोग्राम है जिसे आप अपने VPS पर इंस्टॉल करते हैं। यह GitHub से जॉब्स के लिए अनुरोध करता है और उन्हें आपके हार्डवेयर पर चलाता है। आप इसे एक रिपॉजिटरी के साथ रजिस्टर करते हैं, इसे systemd सर्विस के रूप में इंस्टॉल करते हैं, और यह हर रीबूट के बाद अपने आप चालू हो जाता है। GitHub जॉब को शेड्यूल करता है। आपका सर्वर काम पूरा करता है।

अपने खुद के सर्वर पर CI (continuous integration) का उपयोग करने के दो मुख्य लाभ हैं। बिल्ड मिनट्स की गणना बंद हो जाती है, और एक जॉब उन संसाधनों तक पहुँच सकती है जो केवल आपकी मशीन पर उपलब्ध हैं, जैसे कि वार्म बिल्ड कैश या प्राइवेट नेटवर्क। इसकी कीमत सुरक्षा है। रनर वर्कफ़्लो फ़ाइल में दिए गए किसी भी निर्देश को उस यूजर के रूप में निष्पादित करता है जिसे आपने अनुमति दी है, इसलिए वर्कफ़्लो फ़ाइल डिज़ाइन के अनुसार ही रिमोट कोड निष्पादन (remote code execution) है। एक प्राइवेट रिपॉजिटरी पर यह ठीक है, क्योंकि केवल आपके भरोसेमंद लोग ही इसमें बदलाव कर सकते हैं। एक पब्लिक रिपॉजिटरी पर यह एक वास्तविक जोखिम है, और fork pull requests वाला सेक्शन इसके तंत्र को समझाता है।

नीचे दी गई सभी जानकारी Ubuntu 24.04 और runner वर्जन 2.336.0 के लिए है, जो जुलाई 2026 तक का वर्तमान रिलीज है।

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

एक ऐसे 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 यूजर के रूप में कार्य करें।

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 एक्शन निष्पादित (execute) होते हैं।

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

रनर डिपेंडेंसी इंस्टॉल करें

रनर एक .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 वह नाम है जिससे रनर रिपॉजिटरी में दिखाई देता है, इसलिए ऐसा नाम चुनें जिसे आप छह महीने बाद भी पहचान सकें। --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 तक नहीं पहुँच पा रहा है।

रनर को जॉब भेजें

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 का मार्गदर्शन स्पष्ट है: सेल्फ-होस्टेड रनर्स का उपयोग "पब्लिक रिपॉजिटरीज के लिए लगभग कभी नहीं किया जाना चाहिए", और उनमें "अस्थायी क्लीन वर्चुअल मशीनों में चलने की कोई गारंटी नहीं होती है, और वर्कफ़्लो में मौजूद अविश्वसनीय कोड द्वारा उन्हें स्थायी रूप से ब्रीच (compromised) किया जा सकता है"।

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

अप्रूवल सेटिंग्स इसे ठीक किए बिना थोड़ा कम जोखिम भरा बनाती हैं। पब्लिक रिपॉजिटरी के लिए डिफ़ॉल्ट नीति एक मेंटेनर से पहली बार योगदान देने वाले के फोर्क वर्कफ़्लो को अप्रूव करने के लिए कहती है। एक बार जब आप उस व्यक्ति को अप्रूव कर देते हैं, तो उनके बाद के पुल रिक्वेस्ट बिना किसी नए प्रॉम्प्ट के चलते हैं। इसलिए सुरक्षा का दायरा हर बार एक इंसान द्वारा डिफ (diff) पढ़ने पर निर्भर करता है, और बिल्ड स्क्रिप्ट में तीन स्तर नीचे छिपा हुआ पेलोड आसानी से छूट सकता है।

फोर्क पुल रिक्वेस्ट को आपके सीक्रेट्स नहीं मिलते हैं, और इसका GITHUB_TOKEN रीड-ओनली होता है। यह GitHub के भीतर नुकसान को सीमित करता है। यह आपके सर्वर के लिए कुछ नहीं करता है। हमलावर के पास gharunner के रूप में एक शेल होता है, इसलिए वे हर उस फ़ाइल को पढ़ सकते हैं जिसे वह यूजर पढ़ सकता है, प्राइवेट नेटवर्क पर VPS जिस भी चीज़ तक पहुँच सकता है वहाँ तक पहुँच सकते हैं, और ~/.bashrc या किसी यूजर systemd यूनिट में कुछ ऐसा छोड़ सकते हैं जो अगले जॉब के दौरान चलता है।

--ephemeral के साथ रजिस्टर करने से रनर एक जॉब स्वीकार करता है और फिर डी-रजिस्टर हो जाता है, इसलिए एक जॉब अगले जॉब के वर्कस्पेस को नहीं पढ़ सकता है। यह केवल तभी मदद करता है यदि कोई चीज़ प्रत्येक जॉब के लिए मशीन या कंटेनर को फिर से बनाती है, क्योंकि रनर यूजर की होम डायरेक्टरी में लिखा गया बैकडोर नए रजिस्ट्रेशन के बाद भी बना रहता है।

नीचे दिए गए नियम संक्षिप्त हैं। सेल्फ-होस्टेड रनर्स का उपयोग केवल प्राइवेट रिपॉजिटरीज के लिए करें। यदि आपको इसे किसी पब्लिक रिपॉजिटरी से जोड़ना ही है, तो उस पर फोर्क पुल रिक्वेस्ट न चलाएं, उस सर्वर पर कुछ और न रखें, और मशीन को डिस्पोजेबल (नष्ट करने योग्य) मानें।

Docker जॉब्स, और वह ग्रुप जो वास्तव में root है

कंटेनर जॉब्स, सर्विस कंटेनर और कोई भी वर्कफ़्लो स्टेप जो docker build को कॉल करता है, उसे रनर होस्ट पर Docker डेमन की आवश्यकता होती है। Docker को सामान्य तरीके से इंस्टॉल करें, जिसे Docker and Docker Compose on a VPS में कवर किया गया है, फिर रनर यूजर को docker ग्रुप में जोड़ें।

ऐसा करने से पहले इसके परिणामों को समझ लें। docker ग्रुप की सदस्यता root के बराबर है, क्योंकि एक कंटेनर / को बाइंड माउंट कर सकता है और उसके अंदर root के रूप में चल सकता है। इसलिए, जो वर्कफ़्लो Docker सॉकेट से बात कर सकता है, वह VPS पर हर फ़ाइल को पढ़ और लिख सकता है, जिसमें /etc/shadow भी शामिल है। एक प्राइवेट रिपॉजिटरी जिसमें विश्वसनीय योगदानकर्ता हों, वहां यह एक स्वीकार्य समझौता हो सकता है। अन्य किसी भी स्थिति में, यह अनप्रिविलेज्ड यूजर के उद्देश्य को ही समाप्त कर देता है। Rootless Docker कंटेनर बिल्ड्स को रनर यूजर के अपने अधिकारों के भीतर रखता है, लेकिन इसकी कीमत धीमे स्टोरेज ड्राइवर और प्रिविलेज्ड कंटेनरों के न होने के रूप में चुकानी पड़ती है।

अपडेट और रनर को सुरक्षित रूप से हटाना

सेल्फ-होस्टेड रनर डिफ़ॉल्ट रूप से खुद को अपडेट कर लेता है। यह एक नया release आने पर उसे पहचान लेता है, अपनी फ़ाइलों को बदलता है और service को restart कर देता है, इसलिए सामान्यतः आपको कुछ करने की आवश्यकता नहीं होती है। जब आपको एक fixed version की आवश्यकता हो, तो ./config.sh --disableupdate का उपयोग करके self-update को बंद किया जा सकता है। उसके बाद, अपडेट करना आपकी जिम्मेदारी है: GitHub का documentation स्पष्ट करता है कि --disableupdate के साथ कॉन्फ़िगर किए गए रनर को मैन्युअल रूप से अपडेट करना होगा।

मैन्युअल अपडेट करने पर registration बना रहता है, क्योंकि .runner और .credentials tarball में नहीं होते हैं। service को stop करें, नए tarball को डाउनलोड करें और gharunner के रूप में उसका checksum सत्यापित करें, उसे 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 पेज से प्राप्त होता है, जो रनर के अपने 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 करने से रनर repository में Offline के रूप में सूचीबद्ध रहता है, क्योंकि GitHub को केवल तभी पता चलता है कि वह हट गया है जब रनर स्वयं इसकी सूचना देता है या कोई एडमिन मैन्युअल रूप से entry को delete करता है।

विफलता के प्रकार, उन स्ट्रिंग्स के साथ जो आपको दिखाई देंगी

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

sudo: ./svc.sh: command not found। आप सही डायरेक्टरी में हैं। svc.sh अभी मौजूद नहीं है, क्योंकि config.sh ने अभी तक रजिस्ट्रेशन पूरा नहीं किया है। रनर को रजिस्टर करें, फिर सर्विस इंस्टॉल करें।

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

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

रीबूट के बाद रनर ऑफलाइन होना। systemctl is-enabled 'actions.runner.*' चलाएं। यदि कुछ भी सूचीबद्ध नहीं है, तो ./svc.sh install कभी नहीं चलाया गया था, इसलिए रनर केवल आपके टर्मिनल सत्र के भीतर ही मौजूद था। यदि यूनिट इनेबल्ड है और रनर अभी भी 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 रनर टारबॉल में शामिल नहीं होता है। यह रनर डायरेक्टरी में तब जनरेट होता है जब ./config.sh रजिस्ट्रेशन पूरा कर लेता है, जो सर्विस का नाम बनाने के लिए आपके रिपॉजिटरी और रनर नाम का उपयोग करता है। पहले रनर यूजर के रूप में ./config.sh चलाएं। उसके बाद, sudo ./svc.sh install gharunner स्क्रिप्ट को ढूंढ लेता है और /etc/systemd/system में actions.runner.OWNER-REPO.RUNNER-NAME.service नाम की एक यूनिट लिख देता है।

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

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

क्या मैं पब्लिक रिपॉजिटरी पर सेल्फ-होस्टेड रनर का उपयोग कर सकता हूँ?

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

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

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