Ubuntu 24.04 वर self-hosted GitHub Actions runner सेटअप

self-hosted GitHub Actions runner काय करते

self-hosted GitHub Actions runner हा एक प्रोग्राम आहे जो तुम्ही तुमच्या स्वतःच्या VPS वर इंस्टॉल करता. तो GitHub कडे कामाची (jobs) मागणी करतो आणि ती तुमच्या हार्डवेअरवर कार्यान्वित करतो. तुम्ही तो एका रिपॉझिटरीसाठी रजिस्टर करता, तो systemd सर्व्हिस म्हणून इंस्टॉल करता आणि प्रत्येक रीबूटनंतर तो पुन्हा सुरू होतो. GitHub कामाचे वेळापत्रक ठरवते. तुमचा सर्व्हर ते काम पूर्ण करतो.

तुमच्या मालकीच्या मशीनवर CI (continuous integration) वापरणे दोन कारणांसाठी फायदेशीर आहे. बिल्ड मिनिटांची मर्यादा संपते आणि एखादे काम अशा गोष्टींपर्यंत पोहोचू शकते ज्या फक्त तुमच्या मशीनवर उपलब्ध आहेत, जसे की वॉर्म बिल्ड कॅशे किंवा प्रायव्हेट नेटवर्क. याची किंमत सुरक्षिततेच्या स्वरूपात मोजावी लागते. रनर वर्कफ्लो फाईलमध्ये दिलेली कोणतीही आज्ञा, तुम्ही दिलेल्या युजरच्या अधिकाराने कार्यान्वित करतो. त्यामुळे, वर्कफ्लो फाईल ही डिझाइननुसारच रिमोट कोड एक्झिक्युशन (RCE) आहे. प्रायव्हेट रिपॉझिटरीवर हे ठीक आहे, कारण फक्त तुमच्या विश्वासू व्यक्तीच तिथे बदल करू शकतात. पब्लिक रिपॉझिटरीवर हा एक मोठा धोका आहे आणि fork pull requests वरील विभाग याची कार्यपद्धती स्पष्ट करतो.

खालील सर्व माहिती Ubuntu 24.04 आणि runner version 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 ग्रुपमध्ये आहे आणि तुम्ही तयार केलेले आयसोलेशन (विलगीकरण) नष्ट झाले आहे.

रनर डाउनलोड करा आणि टारबॉल तपासा

येथून पुढे रनर युजर म्हणून काम करा.

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

टार्बॉलमध्ये काय समाविष्ट आहे आणि काय नाही

एक्सट्रॅक्शननंतर डिरेक्टरीमध्ये 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 ही त्रुटी येते. आधी नोंदणी करा, त्यानंतर सर्व्हिस इन्स्टॉल करा.

रनरच्या डिपेंडन्सीज इन्स्टॉल करा

रनर हे एक .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 ला पटवून देतात, त्यामुळे ज्या कोणाला त्या वाचता येतील तो रनरचे रूप धारण करू शकतो. म्हणूनच डिरेक्टरीचा मोड 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 चे मार्गदर्शन स्पष्ट आहे: सेल्फ-होस्टेड रनर्स "पब्लिक रिपॉझिटरीजसाठी जवळजवळ कधीही वापरले जाऊ नयेत" आणि "ते अल्पायुषी (ephemeral) क्लीन व्हर्च्युअल मशीन्सवर चालण्याची कोणतीही खात्री देत नाहीत, तसेच वर्कफ्लोमधील अविश्वसनीय कोडद्वारे ते कायमस्वरूपी तडजोड (compromise) केले जाऊ शकतात".

याची कार्यपद्धती सोपी आहे. फोर्क (fork) कडून आलेली पुल रिक्वेस्ट (pull request) स्वतःची वर्कफ्लो फाईल सोबत घेऊन येते. जर तुमची पब्लिक रिपॉझिटरी तुमच्या रनरवर पुल रिक्वेस्ट वर्कफ्लो चालवत असेल, तर जो कोणी रिपॉझिटरी फोर्क करू शकतो, तो असा वर्कफ्लो सुचवू शकतो जो त्यांच्या कमांड्स तुमच्या VPS वर चालवेल. त्यांना कोणत्याही राईट ॲक्सेसची (write access) गरज नसते, कारण ते जे सुचवत आहेत तेच रनरवर कार्यान्वित होते.

ॲप्रूव्हल सेटिंग्ज (approval settings) यामुळे होणारा धोका कमी करतात, पण तो पूर्णपणे दूर करत नाहीत. पब्लिक रिपॉझिटरीसाठी डीफॉल्ट पॉलिसीनुसार, पहिल्यांदा योगदान देणाऱ्याच्या फोर्क वर्कफ्लोला मेंटेनरने मंजुरी देणे आवश्यक असते. एकदा तुम्ही त्या व्यक्तीला मंजुरी दिली की, त्यांच्या पुढील पुल रिक्वेस्ट कोणत्याही नवीन सूचनेशिवाय चालतात. त्यामुळे, प्रत्येक वेळी मानवी हस्तक्षेपाद्वारे डिफ (diff) तपासणे हाच एकमेव अडथळा उरतो, आणि बिल्ड स्क्रिप्टमध्ये तीन स्तरांखाली लपवलेला मालवेअर शोधणे सोपे नसते.

फोर्क पुल रिक्वेस्टला तुमचे सीक्रेट्स (secrets) मिळत नाहीत आणि तिचा GITHUB_TOKEN हा रीड-ओन्ली असतो. यामुळे GitHub च्या आत होणारे नुकसान मर्यादित राहते. पण तुमच्या सर्व्हरसाठी याचा काहीही उपयोग होत नाही. अटॅकरकडे gharunner म्हणून शेल ॲक्सेस असतो, त्यामुळे ते त्या युजरला वाचता येणाऱ्या सर्व फाईल्स वाचू शकतात, खाजगी नेटवर्कवर VPS जिथे पोहोचू शकतो तिथे पोहोचू शकतात आणि ~/.bashrc मध्ये किंवा युजर सिस्टिमडी युनिटमध्ये (systemd unit) काहीतरी मागे सोडू शकतात जे पुढील जॉब दरम्यान कार्यान्वित होईल.

--ephemeral सह नोंदणी केल्यामुळे रनर एक जॉब पूर्ण करून स्वतःला डी-रजिस्टर करतो, त्यामुळे एक जॉब दुसऱ्या जॉबचे वर्कस्पेस वाचू शकत नाही. हे केवळ तेव्हाच उपयुक्त ठरते जेव्हा प्रत्येक जॉबसाठी मशीन किंवा कंटेनर पुन्हा तयार (rebuild) केले जाते, कारण रनर युजरच्या होम डिरेक्टरीमध्ये लिहिलेला बॅकडोअर नवीन नोंदणीनंतरही तसाच राहतो.

खालील नियम संक्षिप्त आहेत. सेल्फ-होस्टेड रनर्सचा वापर केवळ खाजगी रिपॉझिटरीजसाठी करा. जर तुम्हाला ते पब्लिक रिपॉझिटरीला जोडणे अनिवार्य असेल, तर त्यावर फोर्क पुल रिक्वेस्ट चालवू नका, त्या सर्व्हरवर इतर कोणतीही गोष्ट ठेवू नका आणि त्या मशीनला डिस्पोजेबल (फेकून देण्यायोग्य) समजा.

Docker जॉब्स आणि खऱ्या अर्थाने root असलेला गट

कंटेनर जॉब्स, सर्व्हिस कंटेनर आणि docker build कॉल करणारी कोणतीही वर्कफ्लो स्टेप यासाठी रनर होस्टवर Docker डेमनची आवश्यकता असते. Docker नेहमीच्या पद्धतीने इन्स्टॉल करा, ज्याची माहिती Docker आणि Docker Compose on a VPS मध्ये दिली आहे, त्यानंतर रनर वापरकर्त्याला docker ग्रुपमध्ये जोडा.

हे करण्यापूर्वी त्यातील धोके समजून घ्या. docker ग्रुपचे सदस्यत्व असणे म्हणजे root असण्यासारखेच आहे, कारण एखादा कंटेनर / ला बाइंड माउंट करू शकतो आणि त्यामध्ये root म्हणून रन होऊ शकतो. त्यामुळे, जो वर्कफ्लो Docker सॉकेटशी संवाद साधू शकतो, तो VPS वरील /etc/shadow सह प्रत्येक फाईल वाचू आणि लिहू शकतो. खाजगी रिपॉझिटरीमध्ये आणि विश्वासार्ह योगदानकर्ते असल्यास, ही किंमत स्वीकारार्ह असू शकते. इतर कोणत्याही ठिकाणी, यामुळे अनप्रिव्हिलेज्ड वापरकर्त्याचा उद्देशच संपतो. Rootless Docker कंटेनर बिल्ड्सना रनर वापरकर्त्याच्या स्वतःच्या अधिकारांच्या मर्यादेत ठेवते, परंतु यासाठी संथ स्टोरेज ड्रायव्हर आणि प्रिव्हिलेज्ड कंटेनर नसणे अशा मर्यादा येतात.

अपडेट्स आणि रनर सुरक्षितपणे काढून टाकणे

सेल्फ-होस्टेड रनर डीफॉल्टनुसार स्वतःला अपडेट करतो. जेव्हा नवीन रिलीज उपलब्ध होते, तेव्हा तो स्वतःच्या फाइल्स बदलतो आणि सर्व्हिस पुन्हा सुरू करतो, त्यामुळे सामान्यतः तुम्हाला काहीही करण्याची गरज नसते. जेव्हा तुम्हाला ठराविक व्हर्जनची गरज असते, तेव्हा ./config.sh --disableupdate वापरून तुम्ही सेल्फ-अपडेट बंद करू शकता. त्यानंतर, अपडेट करण्याची जबाबदारी तुमची असते: GitHub च्या डॉक्युमेंटेशनमध्ये स्पष्टपणे नमूद केले आहे की --disableupdate सह कॉन्फिगर केलेला रनर हाताने अपडेट करावा लागतो.

मॅन्युअल अपडेट केल्यामुळे रनरचे रजिस्ट्रेशन कायम राहते, कारण .runner आणि .credentials या फाइल्स टरबॉलमध्ये नसतात. सर्व्हिस थांबवा, नवीन टरबॉल डाउनलोड करा आणि 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 ने नोंदणी प्रक्रिया पूर्ण केलेली नाही. रनरची नोंदणी करा आणि त्यानंतर सर्व्हिस इन्स्टॉल करा.

Http response code: NotFound from 'POST https://api.github.com/actions/runner-registration'. हे टोकन वैध नोंदणी टोकन नाही. एकतर त्याची मुदत संपली आहे, कारण ते केवळ एक तास वैध असते, किंवा रनर्स पेजवरील नोंदणी टोकनच्या जागी वैयक्तिक ॲक्सेस टोकन (personal access token) पेस्ट केले गेले आहे. नवीन टोकन तयार करा आणि ते पुन्हा पेस्ट करा.

Dependencies is missing for Dotnet Core 6.0. रनर डिरेक्टरीमधून sudo ./bin/installdependencies.sh हे root म्हणून चालवा आणि त्यानंतर पुन्हा नोंदणी करा.

रीबूटनंतर रनर ऑफलाइन असणे. systemctl is-enabled 'actions.runner.*' चालवा. जर काहीही सूचीबद्ध नसेल, तर ./svc.sh install कधीही चालवले गेले नव्हते, याचा अर्थ रनर फक्त तुमच्या टर्मिनल सत्रापुरताच मर्यादित होता. जर युनिट इनेबल असेल आणि रनर अजूनही ऑफलाइन असेल, तर journalctl -u 'actions.runner.*' वाचा आणि आउटबाउंड HTTPS तपासा.

डिस्क पूर्ण भरणे. चेकआउट्स, बिल्ड कॅशे आणि Docker इमेजेस _work मध्ये आणि रनर वापरकर्त्याच्या होम डिरेक्टरीमध्ये साठतात आणि त्यांना आपोआप काढून टाकणारी कोणतीही यंत्रणा नाही. du -sh /home/gharunner/actions-runner/_work वर लक्ष ठेवा आणि डिस्क आपोआप भरण्यापूर्वी एक नियोजित स्वच्छता (scheduled clean-up) प्रक्रिया जोडा.

FAQ

sudo ./svc.sh install कमांड सापडली नाही असे का म्हणते?

कारण svc.sh हे रनर टारबॉलमध्ये (runner tarball) नसते. जेव्हा ./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 असे न करण्याचा सल्ला देते. फोर्क (fork) कडून आलेल्या पुल रिक्वेस्टमध्ये स्वतःची वर्कफ्लो फाईल असते, त्यामुळे जो कोणी तुमची रिपॉझिटरी फोर्क करू शकतो, तो तुमच्या मशीनवर चालणाऱ्या कमांड्स सुचवू शकतो. मंजुरीची सूचना (approval prompt) केवळ योगदानकर्त्याच्या पहिल्या रनसाठी असते. जर तुम्ही पब्लिक रिपॉझिटरीला रनर जोडला असेल, तर त्यावर फोर्क पुल रिक्वेस्ट वर्कफ्लो अक्षम करा, त्या सर्व्हरवर इतर काहीही ठेवू नका आणि ठराविक काळाने मशीन पुन्हा तयार (rebuild) करा.

Http response code: NotFound मुळे नोंदणी का अयशस्वी होते?

जेव्हा क्रेडेंशियल चुकीचे असते, तेव्हाही नोंदणी कॉल 'NotFound' असे उत्तर देतो, केवळ URL चुकीची असतानाच नाही, ज्यामुळे हा संदेश दिशाभूल करणारा ठरतो. नोंदणी टोकन्स (registration tokens) दाखवल्यानंतर एका तासाने कालबाह्य होतात आणि या कॉलसाठी पर्सनल ॲक्सेस टोकन स्वीकारले जात नाही. Settings, Actions, Runners, New self-hosted runner पुन्हा उघडा, नवीन टोकन कॉपी करा आणि --url चे मूल्य अशा रिपॉझिटरीकडे निर्देश करत असल्याची खात्री करा जिथे तुम्हाला ॲडमिन अधिकार आहेत.