कैश, साझा और डीबग वर्कफ़्लोज़

पूरा किया

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

इस प्रक्रिया को लागू करने के लिए, आप निम्न कार्य करने का तरीका जानेंगे:

• तेजी से वर्कफ़्लोज़ के लिए कैश निर्भरता।
• नौकरियों के बीच आर्टिफैक्ट डेटा पास करें।
• वर्कफ़्लोज़ के लिए डीबग लॉगिंग सक्षम करें।
• GitHub UI और REST API से वर्कफ़्लो लॉग एक्सेस करें।
• GitHub ऐप प्रमाणीकरण के लिए इंस्टॉलेशन टोकन का उपयोग करें।

कैश क्रिया के साथ कैश निर्भरताएँ

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

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

प्राचल	वर्णन	आवश्यक
Key	कैश को सहेजते और खोजते समय बनाए गए कुंजी पहचानकर्ता को संदर्भित करता है।	हाँ
Path	कैश या खोज करने के लिए धावक पर फ़ाइल पथ को संदर्भित करता है।	हाँ
Restore-keys	वांछित कैश कुंजी नहीं मिलने पर कैश के लिए वैकल्पिक मौजूदा कुंजियों से मिलकर बनता है।	नहीं

steps:
  - uses: actions/checkout@v2

  - name: Cache NPM dependencies
    uses: actions/cache@v2
    with:
      path: ~/.npm
      key: ${{ runner.os }}-npm-cache-${{ hashFiles('**/package-lock.json') }}
      restore-keys: |
        ${{ runner.os }}-npm-cache-

पूर्ववर्ती उदाहरण में, path~/.npm पर सेट है और key में रनर का ऑपरेटिंग सिस्टम और package-lock.json फ़ाइल का SHA-256 हैश शामिल है। एक आईडी के साथ कुंजी को उपसर्ग करना (npm-cache इस उदाहरण में) तब उपयोगी होता है जब आप restore-keys फ़ॉलबैक का उपयोग कर रहे हों और आपके पास कई कैश हों।

नौकरियों के बीच आर्टिफ़ैक्ट डेटा पास करें

अपने वर्कफ़्लो में निर्भरताओं को कैशिंग करने के विचार के समान, आप समान वर्कफ़्लो के अंदर नौकरियों के बीच डेटा पास कर सकते हैं। आप AND upload-artifact क्रियाओं का download-artifact उपयोग करके डेटा पास कर सकते हैं. पिछली नौकरी की कलाकृतियों पर निर्भर नौकरियों को चलाने से पहले पिछली नौकरी के सफलतापूर्वक पूरा होने की प्रतीक्षा करनी चाहिए। यह दृष्टिकोण उपयोगी है यदि आपके पास नौकरियों की एक श्रृंखला है जिसे पहले की नौकरी से अपलोड की गई कलाकृतियों के आधार पर क्रमिक रूप से चलाने की आवश्यकता है। उदाहरण के लिए, job_2job_1 सिंटैक्स का उपयोग करके needs: job_1 की आवश्यकता होती है.

name: Share data between jobs
on: push
jobs:
  job_1:
    name: Upload File
    runs-on: ubuntu-latest
    steps:
      - run: echo "Hello World" > file.txt
      - uses: actions/upload-artifact@v2
        with:
          name: file
          path: file.txt

  job_2:
    name: Download File
    runs-on: ubuntu-latest
    needs: job_1
    steps:
      - uses: actions/download-artifact@v2
        with:
          name: file
      - run: cat file.txt

इस उदाहरण में दो काम हैं। job_1 फ़ाइल में कुछ पाठ लिखता है file.txt । फिर यह इस आर्टिफ़ैक्ट को अपलोड करने और वर्कफ़्लो के भीतर भविष्य में उपयोग के लिए डेटा संग्रहीत करने के लिए actions/upload-artifact@v2 क्रिया का उपयोग करता है। job_2 job_1 सिंटैक्स का उपयोग करके पूरा करने के लिए needs: job_1 की आवश्यकता है। यह तब उस आर्टिफैक्ट को डाउनलोड करने के लिए actions/download-artifact@v2 क्रिया का उपयोग करता है, और फिर file.txtकी सामग्री को प्रिंट करता है।

वर्कफ़्लो में चरण डीबग लॉगिंग सक्षम करें

कुछ मामलों में, डिफ़ॉल्ट वर्कफ़्लो लॉग आपके लिए यह निदान करने के लिए पर्याप्त विवरण प्रदान नहीं करते हैं कि कोई विशिष्ट वर्कफ़्लो चलाएँ, कार्य या चरण विफल क्यों होता है. इन परिदृश्यों में, आप दो विकल्पों के लिए अधिक डीबग लॉगिंग सक्षम कर सकते हैं: रन और चरण। दो रिपॉजिटरी रहस्यों को सेट करके इस नैदानिक लॉगिंग को सक्षम करें जिन्हें रिपॉजिटरी तक पहुंच की आवश्यकता होती admin है true।

• नैदानिक लॉगिंग चलाएँ सक्षम करने के लिए, उस रिपॉज़िटरी में रहस्य सेट ACTIONS_RUNNER_DEBUG करें जिसमें कार्यप्रवाह .true
• चरण नैदानिक लॉगिंग सक्षम करने के लिए, उस रिपॉसिटरी में ACTIONS_STEP_DEBUG रहस्य सेट करें जिसमें वर्कफ़्लो trueपर है.

GitHub में वर्कफ़्लो लॉग तक पहुँचें

जब आप सफल स्वचालन के बारे में सोचते हैं, तो आप कम से कम समय बिताने का लक्ष्य रखते हैं कि क्या स्वचालित है ताकि आप प्रासंगिक चीज़ों पर ध्यान केंद्रित कर सकें। लेकिन कभी-कभी चीजें योजना के अनुसार नहीं होती हैं, और आपको समीक्षा करने की आवश्यकता है कि क्या हुआ। वह डिबगिंग प्रक्रिया निराशाजनक हो सकती है।

GitHub में एक स्पष्ट, संरचित लेआउट है जो आपको वर्तमान डिबगिंग चरण के संदर्भ को बनाए रखते हुए नौकरियों के बीच जल्दी से स्थानांतरित करने में मदद करता है।

GitHub में चलाए गए वर्कफ़्लो के लॉग देखने के लिए:

1. अपने भंडार में, क्रियाएं टैब पर जाएं।
2. बाएँ फलक में, वर्कफ़्लो का चयन करें.
3. वर्कफ़्लो रन की सूची में, रन का चयन करें.
4. कार्य के अंतर्गत, कार्य का चयन करें.
5. लॉग आउटपुट पढ़ें।

यदि आपके पास वर्कफ़्लो के अंदर कई रन हैं, तो आप अपने वर्कफ़्लो का चयन करने के बाद स्थिति फ़िल्टर का चयन कर सकते हैं और उस वर्कफ़्लो में केवल विफल रन प्रदर्शित करने के लिए इसे विफलता पर सेट कर सकते हैं.

REST API से वर्कफ़्लो लॉग तक पहुँचें

GitHub के माध्यम से लॉग देखने के अलावा, आप वर्कफ़्लो रन के लिए लॉग देखने, वर्कफ़्लोज़ को फिर से चलाने या वर्कफ़्लो रन रद्द करने के लिए GitHub REST API का उपयोग कर सकते हैं। API का उपयोग करके वर्कफ़्लो रन का लॉग देखने के लिए, लॉग समापन बिंदु पर एक GET अनुरोध भेजें. ध्यान रखें कि रिपॉजिटरी तक रीड एक्सेस रखने वाला कोई भी व्यक्ति इस एंडपॉइंट का उपयोग कर सकता है। यदि रिपॉजिटरी निजी है, तो आपको repo दायरे के साथ एक्सेस टोकन का उपयोग करना चाहिए।

उदाहरण के लिए, किसी विशिष्ट वर्कफ़्लो रन लॉग को देखने के लिए अनुरोध GET इस पथ का अनुसरण करता है:

GET /repos/{owner}/{repo}/actions/runs/{run_id}/logs

पहचानें कि GitHub ऐप से इंस्टॉलेशन टोकन का उपयोग कब करना है

जब आपका GitHub ऐप किसी खाते पर इंस्टॉल हो जाता है, तो आप REST और GraphQL API अनुरोधों का उपयोग करके इसे ऐप इंस्टॉलेशन के रूप में installation access token प्रमाणित कर सकते हैं। यह चरण ऐप को इंस्टॉलेशन के स्वामित्व वाले संसाधनों तक पहुंचने की अनुमति देता है, यह मानते हुए कि ऐप को आवश्यक रिपॉजिटरी एक्सेस और अनुमतियां दी गई थीं। ऐप इंस्टॉलेशन द्वारा किए गए REST या GraphQL API अनुरोधों का श्रेय ऐप को दिया जाता है।

निम्न उदाहरण में, आप स्थापना पहुँच टोकन के साथ बदलें INSTALLATION_ACCESS_TOKEN :

curl --request GET \
--url "https://api.github.com/meta" \
--header "Accept: application/vnd.github+json" \
--header "Authorization: Bearer INSTALLATION_ACCESS_TOKEN" \
--header "X-GitHub-Api-Version: 2022-11-28"

आप HTTP- आधारित Git एक्सेस के लिए प्रमाणित करने के लिए इंस्टॉलेशन एक्सेस टोकन का भी उपयोग कर सकते हैं। आपके ऐप में Contents रिपॉजिटरी की अनुमति होनी चाहिए। फिर आप HTTP पासवर्ड के रूप में स्थापना पहुँच टोकन का उपयोग कर सकते हैं।

आप उदाहरण में स्थापना पहुँच टोकन के साथ बदलें TOKEN :

git clone https://x-access-token:TOKEN@github.com/owner/repo.git