4 पॉइंट द्वारा GN⁺ 2025-04-09 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • GitHub Actions में run: ब्लॉक चलाते समय इस्तेमाल होने वाला shell, shell keyword से निर्धारित किया जा सकता है
  • workflow में यह वैकल्पिक है, लेकिन individual action definition में यह अनिवार्य है
  • डिफ़ॉल्ट मान OS के अनुसार अपने-आप तय होता है: Linux/macOS में bash, Windows में pwsh
  • अगर shell: bash को स्पष्ट रूप से सेट किया जाए, तो इसमें ये डिफ़ॉल्ट flags भी शामिल होते हैं: --noprofile --norc -eo pipefail

किसी भी executable को shell के रूप में निर्धारित किया जा सकता है

  • आम तौर पर यह मान लेना आसान है कि shell में इस्तेमाल किए जा सकने वाले values सीमित होंगे
  • वास्तव में, $PATH में मौजूद हर executable को shell के रूप में इस्तेमाल किया जा सकता है
  • अगर execution command file input स्वीकार नहीं करता, तो विशेष argument {0} पास करना होता है
  • {0} को GitHub अपने-आप temporary file path से बदल देता है

प्रयोगात्मक उदाहरण

  • C language compiler (tcc) को shell की तरह इस्तेमाल करके सीधे execute करना भी संभव है
  • $PATH को manipulate करके नकली bash shell बनाकर उसका इस्तेमाल करना भी संभव है
  • GitHub को फ़र्क नहीं पड़ता कि shell item में दिया गया मान वास्तव में कौन-सा executable है

सुरक्षा संबंधी संकेत

  • GitHub Actions में file write और execution के बीच की सीमा धुंधली है (GITHUB_ENV, $GITHUB_PATH आदि के ज़रिए भी execution की संभावना रहती है)
  • shell: bash जैसे well-known values भी $PATH के ज़रिए resolve होते हैं, और fixed execution path (/bin/bash) का इस्तेमाल नहीं करते
  • उम्मीद के विपरीत, python जैसे values भी केवल tool cache reference नहीं हैं, बल्कि वास्तविक path-based execution हैं

2 टिप्पणियां

 
tujuc 2025-04-09

github/runner-image रेपो को ही देखें तो काफ़ी सारे ऐसे पैकेज पहले से इंस्टॉल मिलते हैं जिन्हें सीधे इस्तेमाल किया जा सकता है....

इमेज बनाते ही आराम से 1GB तो चला ही जाता है....

 
GN⁺ 2025-04-09
Hacker News की राय
  • पहले bash के -x फ़्लैग का उपयोग करके Actions workflow में चलने वाले हर command को प्रिंट करने के लिए मजबूर किया था। यह debugging में बहुत उपयोगी है
  • काम करते समय GitHub Actions की एक शानदार अनौपचारिक trick मिली: wildcard का उपयोग करके repository_dispatch event name को match करना
    • यह centralized release pipeline के ज़रिए define किए गए reusable workflow को enforce करने का एकमात्र तरीका है
    • event dispatch करते समय product और version को आसानी से identify किया जा सकता है
  • अनुभव से लगता है कि GitHub Actions में जितना कम काम किया जाए, उतना बेहतर है
    • logic को encode करने के लिए build system (जैसे Make) का उपयोग करके उसे GitHub Actions से call करना, या
    • एक छोटा CLI program लिखकर उसे GitHub Actions से call करना पसंद है
    • local में debug करना, CI में debug करने की तुलना में बहुत आसान है
  • एक पीढ़ी थी जो spreadsheet को code में बदलने के अनुरोध से डरती थी
    • वही पीढ़ी GitHub Actions से बने deployment में अनुशासन लाने के अनुरोध से भी डरेगी
  • Github Actions Runner का code पढ़ने में आसान है
    • लोकप्रिय shell/binary के लिए default arguments define करने की एक खास जगह है
    • ScriptHandler.cs में process environment, arguments आदि तैयार करने वाला सारा code है
    • कुल मिलाकर, इस code की सादगी देखकर सकारात्मक रूप से आश्चर्य हुआ
  • default shell bash को चकमा देकर किसी भी program को चलाया जा सकता है
    • जब तक दूसरे action के पाठक समझते हों कि क्या हो रहा है, यह बहुत उपयोगी है
    • shell script के कुछ लाइनों से शुरू होकर सौ से ज़्यादा लाइनों के monster में बदल जाने का अनुभव रहा है
    • Python stdlib की arrays और types जैसी सुविधाएँ चाहिए थीं
  • इससे उम्मीद मिलती है कि GitHub workflow YAML file में CI jobs को सीधे चलाने वाला Go code आसानी से चलाया जा सकेगा
    • goeval अभी सीधे file input support नहीं करता
    • shell trick की ज़रूरत है
    • थोड़ा boilerplate चाहिए
    • मैं goeval का लेखक हूँ
  • सोचता हूँ कि Github CI yaml का फायदा आखिर क्या है
  • अब CI/CD में C लिखकर उसे low-level system work कहा जा सकता है
    • शायद assembly भी लिखी जा सकती है