GitHub Actions: सर्वोत्तम तरीके

यह कार्यरत दस्तावेज़ GitHub Actions का उपयोग करने के लिए सर्वोत्तम प्रथाओं का संग्रह है। अगर आपके पास कोई सुझाव या जोड़ने के लिए कुछ है, तो कृपया GitHub पर एक पुल रिक्वेस्ट खोलिए!

• GitHub Actions: सर्वोत्तम प्रथाएँ
  • सर्वोत्तम प्रथाओं का संग्रह
    • वर्कफ्लो के लिए टाइमआउट तय कीजिए
      • उदाहरण
    • विचार कीजिए कि क्या (तीसरे पक्ष के) एक्शन सचमुच ज़रूरी हैं
    • वर्कफ्लो टोकन का दायरा सीमित कीजिए
      • उदाहरण
    • एक्शन को SHA पर पिन कीजिए
      • कमिट SHA ढूँढना
      • उदाहरण
    • टेस्ट रनर को वर्शन पर पिन कीजिए
      • उदाहरण
    • कॉनकरेंसी रणनीति बनाने पर विचार कीजिए
      • उदाहरण
    • विचार कीजिए कि कौन-से ट्रिगर सचमुच ज़रूरी हैं
    • "GitHub Actions के लिए सुरक्षा मज़बूत करना" गाइड पढ़िए
  • वर्कफ्लो चेकलिस्ट

सर्वोत्तम प्रथाओं का संग्रह

वर्कफ्लो के लिए टाइमआउट तय कीजिए

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

सही टाइमआउट हर वर्कफ्लो पर निर्भर करता है, लेकिन Exercism के रेपो में इस्तेमाल होने वाले वर्कफ्लो के लिए 30 मिनट आम तौर पर पर्याप्त से अधिक होते हैं।

इसके ये फायदे हैं:

• PR पूरे दिन CI में लंबित नहीं रहेंगे, समस्याएँ जल्दी पकड़ी जा सकती हैं या वर्कफ्लो रन दोबारा शुरू किए जा सकते हैं।
• कुल समानांतर बिल्ड की संख्या सीमित होती है, इसलिए अगर अटके हुए जॉब जल्दी रद्द कर दिए जाएँ, तो वे दूसरे PR के लिए समस्या नहीं बनेंगे।

उदाहरण

jobs:
  configlet:
    timeout-minutes: 30
    runs-on: ubuntu-latest
    steps:
      - [...]

विचार कीजिए कि क्या (तीसरे पक्ष के) एक्शन सचमुच ज़रूरी हैं

एक्शन को आपकी पसंदीदा प्रोग्रामिंग भाषा की डिपेंडेंसी की तरह मानना चाहिए¹। ये तीसरे पक्ष के लेखकों द्वारा लिखा गया कोड होता है, जो Exercism के नियंत्रण से बाहर है। भले ही आप एक्शन के लेखकों पर भरोसा करते हों, फिर भी रिपॉज़िटरी पर किसी शत्रुतापूर्ण कब्ज़े का खतरा रहता है, जो उन लोगों को परोक्ष रूप से Exercism के रेपो तक पहुँच देगा, लिखने की पहुँच समेत।

इसलिए आपको ध्यान से सोचना चाहिए कि कोई नया एक्शन जोड़ना सचमुच फायदेमंद है या कोड को Exercism के नियंत्रण वाले किसी (नए) एक्शन में डालना बेहतर रहेगा।

यह भी देखिए कि एक्शन पर सक्रिय रूप से काम हो रहा है या नहीं, जैसे रेपो की हाल की गतिविधि देखकर, या यह सुनिश्चित करके कि वह एक्शन किसी व्यक्तिगत खाते के बजाय किसी संस्था का हिस्सा है।

GitHub या Exercism संस्था द्वारा प्रकाशित एक्शन को आम तौर पर बिना खास सोच-विचार के शामिल करना (लगभग) सुरक्षित माना जा सकता है।

वर्कफ्लो टोकन का दायरा सीमित कीजिए

डिफॉल्ट रूप से वर्कफ्लो को दिए गए एक्सेस टोकन के पास पढ़ने और लिखने, दोनों के लिए व्यापक अनुमतियाँ होती हैं।

न्यूनतम विशेषाधिकार का सिद्धांत वर्कफ्लो पर भी लागू किया जाना चाहिए।

आप हर वर्कफ्लो के लिए अलग-अलग तय कर सकते हैं कि उसे कौन-सी अनुमतियाँ चाहिए।

उदाहरण

अगर किसी वर्कफ्लो को रेपो की सामग्री सिर्फ पढ़नी है, उसमें लिखना नहीं, जैसे कि वह एक साधारण CI जाँच है, तो आप टोकन को इस तरह सीमित कर सकते हैं:

permissions:
  contents: read

अनुमतियों की पूरी सूची के लिए GitHub Docs देखिए।

एक्शन को SHA पर पिन कीजिए

दूसरे एक्शन इस्तेमाल करते समय उन्हें किसी कमिट (उसके SHA के ज़रिए) पर पिन कीजिए, न कि किसी ब्रांच या टैग पर। इससे यह सुनिश्चित होता है कि हर बार वही कोड चलेगा, जो ब्रांच या टैग पर पिन करने पर तय नहीं होता।

इसके दो फायदे हैं:

1. यह आपके बिल्ड को स्थिर बनाता है
2. यह किसी हमलावर को ब्रांच/टैग को दुर्भावनापूर्ण कोड की ओर इशारा करने के लिए बदलने से रोकता है

इस नियम का एकमात्र अपवाद वे एक्शन हो सकते हैं जिन्हें हमने (Exercism ने) खुद बनाया है।

कमिट SHA ढूँढना

आम तौर पर आप किसी खास रिलीज़ के कमिट SHA पर पिन करना चाहते हैं। किसी रिलीज़ का कमिट SHA ढूँढने के लिए एक्शन की रिपॉज़िटरी के रिलीज़ पेज पर जाइए (जैसे https://github.com/actions/checkout/releases)। जिस रिलीज़ का उपयोग करना है उसे ढूँढिए और रिलीज़ के बाईं ओर सारांश वाले हिस्से में दिए छोटे SHA (जैसे a12a394) पर क्लिक कीजिए। इसके बाद आपको रिलीज़ के विवरण वाले पेज पर भेज दिया जाएगा, जहाँ वह पूरा कमिट SHA दिया होता है जिसे आप इस्तेमाल कर सकते हैं।

उदाहरण

- name: Checkout code
  uses: actions/checkout@a12a3943b4bdde767164f792f33f40b04645d846

टेस्ट रनर को वर्शन पर पिन कीजिए

अधिकांश वर्कफ्लो GitHub के समर्थित रनर पर चलते हैं। इनमें से कोई रनर इस्तेमाल करते समय नवीनतम वर्शन के बजाय कोई निश्चित वर्शन इस्तेमाल कीजिए।

इससे यह सुनिश्चित होता है कि वर्कफ्लो हमेशा उसी रनर पर चलेगा, जो आपके बिल्ड को स्थिर बनाता है।

उदाहरण

यह इस्तेमाल कीजिए:

runs-on: ubuntu-22.04

इसके बजाय यह नहीं:

runs-on: ubuntu-latest

कॉनकरेंसी रणनीति बनाने पर विचार कीजिए

अगर इस बीच कोई नया कमिट पुश हो चुका है, तो बीच के कमिट पर CI चलाना अक्सर ज़रूरी या उपयोगी नहीं होता।

आप कॉनकरेंसी रणनीति तय कर सकते हैं, ताकि एक ही कॉन्टेक्स्ट में चल रहे वर्कफ्लो अपने आप रद्द हो जाएँ।

उदाहरण

किसी PR में बीच के बिल्ड रद्द करने के लिए आप ये कॉनकरेंसी सेटिंग्स इस्तेमाल कर सकते हैं:

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: ${{ startsWith(github.ref, 'refs/pull/') }}

विचार कीजिए कि कौन-से ट्रिगर सचमुच ज़रूरी हैं

"GitHub Actions के लिए सुरक्षा मज़बूत करना" गाइड पढ़िए

ऊपर बताई गई प्रथाएँ पूरी सूची नहीं हैं। GitHub Actions का सुरक्षित रूप से उपयोग करने के लिए अच्छी सुरक्षा प्रथाओं की विस्तृत गाइड के लिए GitHub की सुरक्षा गाइड देखिए।

वर्कफ्लो चेकलिस्ट

आप इस चेकलिस्ट की मदद से देख सकते हैं कि कोई वर्कफ्लो सर्वोत्तम प्रथाओं का पालन करता है या नहीं। यह चेकलिस्ट पूरी होने के लिए नहीं है, बल्कि सबसे ज़रूरी बातों पर ध्यान देती है।