गिटहब एक्शन और पेज के साथ गिटहब इवेंट डेटा कैसे प्रकाशित करें

GitHub पर काम करने वाली टीमें सहयोग करने के लिए इवेंट डेटा पर भरोसा करती हैं। समस्या के रूप में रिकॉर्ड किया गया डेटा, पुल अनुरोध, और टिप्पणियां परियोजना को समझने के लिए महत्वपूर्ण हो जाती हैं।

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

और, अगर आप मेरी तरह हैं, तो आप GitHub के अंक की टिप्पणियों को 90 के दशक के एक शानदार गेस्टबुक पेज में बदल सकते हैं।

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

वर्कफ्लो कैसे ट्रिगर किया जाता है, इसके साथ GitHub Actions पर एक परिचयात्मक नज़र के लिए, GitHub Actions के साथ एक हल्का, टूल-एग्नोस्टिक CI/CD फ्लो देखें।

GitHub ईवेंट डेटा एक्सेस करना

एक क्रिया वर्कफ़्लो कुछ डिफ़ॉल्ट परिवेश चर वाले परिवेश में चलता है। इवेंट डेटा सहित बहुत सी सुविधाजनक जानकारी यहाँ उपलब्ध है। इवेंट डेटा तक पहुंचने का सबसे संपूर्ण तरीका $GITHUB_EVENT_PATH . का उपयोग करना है चर, संपूर्ण JSON ईवेंट पेलोड के साथ फ़ाइल का पथ।

विस्तारित पथ /home/runner/work/_temp/_github_workflow/event.json जैसा दिखता है और इसका डेटा इसके webhook ईवेंट से मेल खाता है। आप GitHub REST API ईवेंट प्रकार और पेलोड में webhook ईवेंट डेटा के लिए दस्तावेज़ीकरण पा सकते हैं। JSON डेटा को वर्कफ़्लो वातावरण में उपलब्ध कराने के लिए, आप jq . जैसे टूल का उपयोग कर सकते हैं ईवेंट डेटा को पार्स करने और उसे एक पर्यावरण चर में डालने के लिए।

नीचे, मैं एक समस्या टिप्पणी घटना से टिप्पणी आईडी लेता हूं:

ID="$(jq '.comment.id' $GITHUB_EVENT_PATH)"

अधिकांश ईवेंट डेटा github.event . के माध्यम से भी उपलब्ध है JSON को पार्स करने की आवश्यकता के बिना संदर्भ चर। फ़ील्ड को डॉट नोटेशन का उपयोग करके एक्सेस किया जाता है, जैसा कि नीचे दिए गए उदाहरण में है जहां मैं वही कमेंट आईडी लेता हूं:

ID=${{ github.event.comment.id }}

मेरी गेस्टबुक के लिए, मैं उपयोगकर्ता के हैंडल, और दिनांक और समय के साथ प्रविष्टियां प्रदर्शित करना चाहता हूं। मैं इस घटना डेटा को इस प्रकार कैप्चर कर सकता हूं:

AUTHOR=${{ github.event.comment.user.login }}
DATE=${{ github.event.comment.created_at }}

शेल चर डेटा तक पहुँचने के लिए आसान हैं, हालाँकि, वे अल्पकालिक हैं। प्रत्येक रन में कार्यप्रवाह वातावरण नए सिरे से बनाया जाता है, और यहां तक ​​कि एक चरण में सेट किए गए शेल चर भी अन्य चरणों के लिए बने नहीं रहते हैं। कैप्चर किए गए डेटा को बनाए रखने के लिए, आपके पास दो विकल्प हैं:कलाकृतियों का उपयोग करें, या इसे रिपॉजिटरी के लिए प्रतिबद्ध करें।

ईवेंट डेटा को संरक्षित करना:कलाकृतियों का उपयोग करना

कलाकृतियों का उपयोग करके, आप कार्यप्रवाह नौकरियों के बीच डेटा को अपने भंडार में जमा किए बिना जारी रख सकते हैं। यह तब आसान होता है, जब, उदाहरण के लिए, आप डेटा को कहीं और स्थायी रखने से पहले उसे बदलना या शामिल करना चाहते हैं। वर्कफ़्लो नौकरियों के बीच डेटा बनाए रखना आवश्यक है क्योंकि:

कार्यप्रवाह में प्रत्येक कार्य आभासी वातावरण के एक नए उदाहरण में चलता है। जब कार्य पूरा हो जाता है, तो धावक वर्चुअल वातावरण के उदाहरण को समाप्त कर देता है और हटा देता है। (कलाकृतियों का उपयोग कर कार्यप्रवाह डेटा जारी रखना)

कलाकृतियों का उपयोग करने में दो क्रियाएं सहायता करती हैं:upload-artifact और download-artifact . आप इन क्रियाओं का उपयोग समान कार्यप्रवाह में अन्य कार्यों के लिए फ़ाइलें उपलब्ध कराने के लिए कर सकते हैं। पूरे उदाहरण के लिए, वर्कफ़्लो में नौकरियों के बीच डेटा पास करना देखें।

upload-artifact कार्रवाई का action.yml कीवर्ड की व्याख्या शामिल है। अपलोड की गई फ़ाइलें .zip . में सहेजी जाती हैं प्रारूप। उसी कार्यप्रवाह में एक अन्य कार्य download-artifact का उपयोग कर सकता है दूसरे चरण में डेटा का उपयोग करने के लिए कार्रवाई।

आप संग्रह के क्रियाएँ टैब के अंतर्गत वर्कफ़्लो रन पृष्ठ पर संग्रह को मैन्युअल रूप से डाउनलोड भी कर सकते हैं।

नौकरियों के बीच वर्कफ़्लो डेटा को बनाए रखने से रिपॉजिटरी फ़ाइलों में कोई बदलाव नहीं होता है, क्योंकि उत्पन्न कलाकृतियाँ केवल वर्कफ़्लो वातावरण में रहती हैं।

व्यक्तिगत रूप से, शेल वातावरण में काम करने में सहज होने के कारण, मुझे कलाकृतियों के लिए एक संकीर्ण उपयोग का मामला दिखाई देता है, हालांकि मैं उनका उल्लेख नहीं करने के लिए क्षमा चाहता था। नौकरियों के बीच डेटा पास करने के अलावा, वे .zip . बनाने के लिए उपयोगी हो सकते हैं प्रारूप अभिलेखागार, कहते हैं, परीक्षण आउटपुट डेटा। मेरे गेस्टबुक उदाहरण के मामले में, मैंने केवल एक नौकरी में सभी आवश्यक कदम उठाए, नौकरियों के बीच डेटा पास करने की किसी भी आवश्यकता को नकारते हुए।

ईवेंट डेटा को संरक्षित करना:वर्कफ़्लो फ़ाइलों को रिपॉजिटरी में धकेलना

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

कार्यप्रवाह में फ़ाइलें बनाना

वर्कफ़्लो में रिपॉजिटरी फ़ाइलों के साथ काम करने के लिए, checkout . का उपयोग करें इसके साथ काम करने के लिए पहले एक प्रति प्राप्त करने के लिए कार्रवाई:

- uses: actions/checkout@master
  with:
    fetch-depth: 1

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

- name: Turn comment into file
  run: |
    ID=${{ github.event.comment.id }}
    AUTHOR=${{ github.event.comment.user.login }}
    DATE=${{ github.event.comment.created_at }}
    COMMENT=$(echo "${{ github.event.comment.body }}")
    NO_TAGS=${COMMENT//[<>]/\`}
    FOLDER=comments

    printf '%b\n' "<div class=\"comment\"><p>${AUTHOR} says:</p><p>${NO_TAGS//$'\n'/\<\/p\>\<p\>}</p><p>${DATE}</p></div>\r\n" > ${FOLDER}/${ID}.html

printf . का उपयोग करके और इसके आउटपुट को > . के साथ निर्देशित कर रहा है एक नई फ़ाइल में, ईवेंट डेटा एक HTML फ़ाइल में रूपांतरित हो जाता है, जिसका नाम टिप्पणी आईडी संख्या होता है, जिसमें कैप्चर किया गया ईवेंट डेटा होता है। स्वरूपित, ऐसा दिखता है:

<div class="comment">
  <p>victoriadrake says:</p>
  <p>This is a comment!</p>
  <p>2019-11-04T00:28:36Z</p>
</div>

टिप्पणियों के साथ काम करते समय, टिप्पणी आईडी का उपयोग करके फ़ाइलों के नामकरण का एक प्रभाव यह है कि समान आईडी वाली एक नई फ़ाइल पिछले को अधिलेखित कर देगी। यह एक गेस्टबुक के लिए आसान है, क्योंकि यह किसी टिप्पणी में किसी भी संपादन को मूल टिप्पणी फ़ाइल को बदलने की अनुमति देता है।

यदि आप ह्यूगो जैसे स्थिर साइट जनरेटर का उपयोग कर रहे हैं, तो आप एक मार्कडाउन प्रारूप फ़ाइल बना सकते हैं, इसे अपने content/ में चिपका सकते हैं। फ़ोल्डर, और नियमित साइट निर्माण बाकी का ख्याल रखेगा।

मेरी सरल अतिथि पुस्तिका के मामले में, मेरे पास व्यक्तिगत टिप्पणी फ़ाइलों को एक पृष्ठ में समेकित करने के लिए एक अतिरिक्त कदम है। हर बार चलने पर, यह मौजूदा index.html . को अधिलेखित कर देता है header.html . के साथ भाग (> ), फिर ढूँढता है और जोड़ता है (>> ) सभी टिप्पणी फ़ाइलों की सामग्री अवरोही क्रम में, और अंत में footer.html संलग्न करती है पृष्ठ को समाप्त करने के लिए भाग।

- name: Assemble page
  run: |
    cat header.html > index.html
    find comments/ -name "*.html" | sort -r | xargs -I % cat % >> index.html
    cat footer.html >> index.html

रिपॉजिटरी में परिवर्तन करना

checkout . के बाद से कार्रवाई काफी हद तक रिपॉजिटरी की क्लोनिंग के समान नहीं है, लेखन के समय, कुछ मुद्दों पर काम करना बाकी है। pull . के लिए कुछ अतिरिक्त चरण आवश्यक हैं , checkout , और सफलतापूर्वक push वापस master में बदल जाता है शाखा, लेकिन यह खोल में बहुत ही मामूली रूप से किया जाता है।

नीचे वह चरण है जो वर्कफ़्लो द्वारा किए गए परिवर्तनों को रिपोजिटरी के master में वापस जोड़ता है, करता है और पुश करता है शाखा।

- name: Push changes to repo
  run: |
    REMOTE=https://${{ secrets.GITHUB_TOKEN }}@github.com/${{ github.repository }}
    git config user.email "${{ github.actor }}@users.noreply.github.com"
    git config user.name "${{ github.actor }}"

    git pull ${REMOTE}
    git checkout master
    git add .
    git status
    git commit -am "Add new comment"
    git push ${REMOTE} master

रिमोट, वास्तव में, हमारा भंडार, github.repository . का उपयोग करके निर्दिष्ट किया गया है संदर्भ चर। हमारे वर्कफ़्लो को मास्टर की ओर धकेलने की अनुमति देने के लिए, हम secrets.GITHUB_TOKEN का उपयोग करते हैं चर।

चूंकि वर्कफ़्लो का वातावरण चमकदार और नवजात है, इसलिए हमें Git को कॉन्फ़िगर करने की आवश्यकता है। उपरोक्त उदाहरण में, मैंने github.actor . का उपयोग किया है कार्यप्रवाह आरंभ करने वाले खाते के उपयोगकर्ता नाम को इनपुट करने के लिए संदर्भ चर। ईमेल को इसी तरह डिफ़ॉल्ट noreply . का उपयोग करके कॉन्फ़िगर किया गया है GitHub ईमेल पता।

ईवेंट डेटा प्रदर्शित करना

नवंबर 6, 2019 सुधार:GitHub Actions के लिए पेज साइट बिल्ड को ट्रिगर करने के लिए एक व्यक्तिगत एक्सेस टोकन की आवश्यकता होती है।

यदि आप डिफ़ॉल्ट secrets.GITHUB_TOKEN के साथ GitHub पेज का उपयोग कर रहे हैं वेरिएबल और साइट जनरेटर के बिना, वर्कफ़्लो में रिपोजिटरी में परिवर्तनों को धक्का देने से केवल रिपोजिटरी फ़ाइलों को अपडेट किया जाएगा। GitHub पेज बिल्ड एक त्रुटि के साथ विफल हो जाएगा, "आपकी साइट को बनाने में समस्या हो रही है:पेज बिल्ड विफल रहा।"

एक पेज साइट निर्माण को ट्रिगर करने के लिए कार्रवाइयां सक्षम करने के लिए, आपको एक व्यक्तिगत एक्सेस टोकन बनाना होगा। इस टोकन को रिपोजिटरी सेटिंग्स में एक गुप्त के रूप में संग्रहीत किया जा सकता है और डिफ़ॉल्ट secrets.GITHUB_TOKEN के स्थान पर कार्यप्रवाह में पारित किया जा सकता है। चर। मैंने इस पोस्ट में Actions के माहौल और वेरिएबल के बारे में और लिखा है।

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

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

- name: Run Makefile
  env:
    TOKEN: ${{ secrets.GITHUB_TOKEN }}
  run: make all

यह सुनिश्चित करता है कि आपके कार्यप्रवाह का अंतिम चरण अद्यतन साइट का निर्माण और परिनियोजन करता है।

कोई और ईवेंट डेटा क्षितिज नहीं

GitHub Actions इवेंट डेटा को कैप्चर करने और उसका उपयोग करने का एक साफ-सुथरा तरीका प्रदान करता है ताकि यह न केवल GitHub के भीतर उपलब्ध हो। संभावनाएं उतनी ही सीमित हैं जितनी आपकी कल्पना! यहां उन चीजों के लिए कुछ उपाय दिए गए हैं जिनसे हम इसे बना सकते हैं:

1. सार्वजनिक मुद्दों का बोर्ड, जहां गिटहब खातों के बिना ग्राहक परियोजना के मुद्दों को देख और प्रतिक्रिया दे सकते हैं।
2. किसी भी रिपॉजिटरी के लिए नए मुद्दों, टिप्पणियों, या पीआर की स्वचालित रूप से अपडेट होने वाली आरएसएस फ़ीड।
3. स्थिर साइटों के लिए एक टिप्पणी प्रणाली, एक इनपुट पद्धति के रूप में GitHub मुद्दे टिप्पणियों का उपयोग करना।
4. 90 के दशक का एक शानदार गेस्टबुक पेज।

क्या मैंने उल्लेख किया कि मैंने 90 के दशक का गेस्टबुक पेज बनाया है? मेरा इनर-जियोसिटीज-बेवकूफ थोड़ा उत्साहित है।