10 मिनट में अपना runner रजिस्टर करें

आपकी मशीन public internet पर नहीं, एक private Tailscale network पर है। इसलिए ढूँढने के लिए कोई खुला SSH port नहीं है, और सुरक्षित करने को कुछ नहीं। अंदर जाने के लिए दो चीज़ें चाहिए, बस एक बार।

Tailscale को tailscale.com/download से इंस्टॉल करें और साइन इन करें। निजी इस्तेमाल के लिए यह मुफ़्त है। ज़्यादातर टीमों को यहाँ जितने बड़े खाते चाहिए, उनके लिए भी मुफ़्त है। यह macOS, Linux और Windows पर चलता है। फिर मशीन तैयार होने पर हम जो share invite भेजते हैं, उसे स्वीकार करें। इससे आपको सिर्फ़ उसी एक मशीन का एक्सेस मिलता है, हमारे network पर और किसी चीज़ का नहीं।

आपका पोर्टल सही कमांड दिखाता है, जिसमें आपकी मशीन का address पहले से भरा होता है:

ssh runner@100.x.x.x

संभालने के लिए कोई पासवर्ड या key नहीं है। authentication Tailscale करता है। अगर आपके Tailscale खाते का ईमेल आपके billing ईमेल से अलग है, तो अपने पोर्टल में उसके लिए share माँगें।

आपके CI jobs को Tailscale की ज़रूरत नहीं है। GitHub Actions, GitHub के अपने outbound कनेक्शन से runner तक पहुँचता है। Tailscale सिर्फ़ तब के लिए है, जब आपको बॉक्स पर shell चाहिए।

CI के लिए SSH काफ़ी है। जब log काफ़ी न हो, तो उसी private network पर screen sharing से उसी मशीन तक पहुँचा जा सकता है। Instruments, Simulator और Xcode का UI वैसे ही चलते हैं जैसे लोकल मशीन पर। आपका पोर्टल address, यूज़र runner, और आपकी लीज़ का अलग पासवर्ड दिखाता है।

Mac पर, Finder खोलें, फिर Go → Connect to Server (⌘K):

vnc://100.x.x.x

Windows पर, RealVNC Viewer या TightVNC इंस्टॉल करें और 100.x.x.x:5900 से कनेक्ट करें। Linux पर, Remmina और TigerVNC दोनों चलते हैं, वही address। अगर आपका client सिर्फ़ पासवर्ड माँगे, तो username खाली छोड़ दें।

ज़्यादातर CI सेवाएँ यह नहीं कर सकतीं। hosted runner आपको सिर्फ़ logs देता है, और कुछ नहीं। इसलिए जो crash सिर्फ़ Instruments में दोहराया जा सकता है, उसकी जाँच आप वहाँ नहीं कर सकते।

अपनी repo (या org) में Settings → Actions → Runners → New runner पर जाएँ। GitHub एक बार इस्तेमाल होने वाला token दिखाता है। इसे आप नीचे वाली कमांड में पेस्ट करेंगे। Org-level runners, org की सभी repos में शेयर होते हैं।

ऊपर बताए तरीके से SSH करें। फिर अपने पोर्टल से configure कमांड चलाएँ (उसमें आपकी मशीन का label पहले से भरा होता है):

cd ~/actions-runner
./config.sh --url https://github.com/YOUR-ORG/YOUR-REPO \
  --token <RUNNER_TOKEN> \
  --labels self-hosted,macOS,macrun-unit-01 \
  --unattended

# start it as a service (survives reboots)
./svc.sh install && ./svc.sh start

runner-agent daemon इस service को अपने आप चालू रखता है। अगर यह crash हो, तो 30 सेकंड के अंदर फिर से शुरू हो जाती है।

अपने workflow को runner पर भेजें। पूरा diff बस इतना है:

 jobs:
   build:
-    runs-on: macos-latest
+    runs-on: [self-hosted, macOS, macrun-unit-01]

आपकी pipeline में बाकी सब बिल्कुल वैसा ही रहता है।

हाल के Xcode रिलीज़ पहले से इंस्टॉल हैं और xcodes से pinned हैं। अपने job में कोई एक चुनें, या अपने पोर्टल से नया वर्ज़न माँगें (आम तौर पर उसी दिन):

- run: sudo xcodes select 26.6
- run: xcodebuild -version

मशीन आपकी है, इसलिए कैश runs के बीच लोकल डिस्क पर बने रहते हैं। दोबारा डाउनलोड का कोई झंझट नहीं। आम paths:

~/Library/Developer/Xcode/DerivedData   # build cache
~/Library/Caches/CocoaPods              # pods
~/.gradle  ~/.npm  ~/.gem               # toolchain caches
~/Library/Caches/org.swift.swiftpm      # SwiftPM

अगर आपको deterministic restore keys चाहिए, तो आप अब भी actions/cache इस्तेमाल कर सकते हैं। पर ज़्यादातर iOS बिल्ड के लिए असली फ़ायदा गरम लोकल डिस्क से है।

Reboot करें, Xcode वर्ज़न माँगें, और billing संभालें, सब अपने पोर्टल से। कुछ और चाहिए? MacRun के किसी भी ईमेल का जवाब दें, और एक इंसान जवाब देगा।