গিটহাব অ্যাকশন এবং পৃষ্ঠাগুলির সাথে কীভাবে গিটহাব ইভেন্ট ডেটা প্রকাশ করবেন

GitHub-এ কাজ করা দলগুলি সহযোগিতার জন্য ইভেন্ট ডেটার উপর নির্ভর করে। সমস্যা, পুল অনুরোধ এবং মন্তব্য হিসাবে রেকর্ড করা ডেটা প্রকল্প বোঝার জন্য গুরুত্বপূর্ণ হয়ে ওঠে।

GitHub অ্যাকশনের সাধারণ উপলব্ধতার সাথে, আমাদের সংগ্রহস্থলে GitHub ইভেন্ট ডেটা প্রোগ্রাম্যাটিকভাবে অ্যাক্সেস এবং সংরক্ষণ করার সুযোগ রয়েছে। তথ্য সংগ্রহস্থলের অংশ তৈরি করা গিটহাবের বাইরে এটি সংরক্ষণ করার একটি উপায়। এটি আমাদেরকে সামনের দিকের ওয়েবসাইটে যেমন GitHub পেজগুলির সাথে ডেটা ফিচার করার ক্ষমতা দেয়৷

এবং, আপনি যদি আমার মতো হন, তাহলে আপনি GitHub ইস্যু মন্তব্যগুলিকে 90-এর দশকের একটি দুর্দান্ত গেস্টবুক পৃষ্ঠায় পরিণত করতে পারেন৷

ব্যবহার যাই হোক না কেন, মূল ধারণাগুলি একই। আমরা GitHub ইভেন্ট ডেটা অ্যাক্সেস, সংরক্ষণ এবং প্রদর্শন করতে অ্যাকশন ব্যবহার করতে পারি - শুধুমাত্র একটি ওয়ার্কফ্লো ফাইলের সাথে। প্রক্রিয়াটি ব্যাখ্যা করার জন্য, আমি আপনাকে ওয়ার্কফ্লো কোডের মাধ্যমে নিয়ে যাব যা আমার গেস্টবুককে উজ্জ্বল করে তোলে।

কীভাবে ওয়ার্কফ্লো ট্রিগার হয় তা সহ গিটহাব অ্যাকশনগুলির একটি পরিচায়ক চেহারার জন্য, গিটহাব অ্যাকশনগুলির সাথে একটি হালকা, টুল-অজ্ঞেয়বাদী CI/CD ফ্লো দেখুন৷

GitHub ইভেন্ট ডেটা অ্যাক্সেস করা

একটি অ্যাকশন ওয়ার্কফ্লো কিছু ডিফল্ট পরিবেশ ভেরিয়েবল সহ একটি পরিবেশে চলে। ইভেন্ট ডেটা সহ এখানে অনেক সুবিধাজনক তথ্য পাওয়া যায়। ইভেন্ট ডেটা অ্যাক্সেস করার সবচেয়ে সম্পূর্ণ উপায় হল $GITHUB_EVENT_PATH ব্যবহার করা পরিবর্তনশীল, সম্পূর্ণ JSON ইভেন্ট পেলোড সহ ফাইলের পথ।

প্রসারিত পথটি /home/runner/work/_temp/_github_workflow/event.json এর মত দেখাচ্ছে এবং এর ডেটা তার ওয়েবহুক ইভেন্টের সাথে মিলে যায়। আপনি GitHub REST API ইভেন্ট টাইপস এবং পেলোডগুলিতে ওয়েবহুক ইভেন্ট ডেটার জন্য ডকুমেন্টেশন খুঁজে পেতে পারেন। ওয়ার্কফ্লো পরিবেশে 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 তৈরির জন্য উপযোগী হতে পারে ফরম্যাট আর্কাইভ, বলুন, টেস্ট আউটপুট ডেটা। আমার গেস্টবুকের উদাহরণের ক্ষেত্রে, আমি কেবল একটি চাকরিতে সমস্ত প্রয়োজনীয় পদক্ষেপগুলি চালিয়েছি, চাকরির মধ্যে ডেটা পাস করার প্রয়োজনকে অস্বীকার করে।

ইভেন্ট ডেটা সংরক্ষণ করা:ভান্ডারে ওয়ার্কফ্লো ফাইল পুশ করা

রিপোজিটরিতে ওয়ার্কফ্লোতে ক্যাপচার করা ডেটা সংরক্ষণ করতে, গিট রিপোজিটরিতে এই ডেটা যোগ করা এবং পুশ করা প্রয়োজন। আপনি ওয়ার্কফ্লোতে ডেটা দিয়ে নতুন ফাইল তৈরি করে বা শেল কমান্ড ব্যবহার করে বিদ্যমান ফাইলগুলিতে ডেটা যুক্ত করে এটি করতে পারেন৷

ওয়ার্কফ্লোতে ফাইল তৈরি করা

ওয়ার্কফ্লোতে রিপোজিটরি ফাইলগুলির সাথে কাজ করতে, 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 ব্যবহার করি পরিবর্তনশীল।

যেহেতু ওয়ার্কফ্লো পরিবেশ চকচকে এবং নবজাতক, তাই আমাদের গিট কনফিগার করতে হবে। উপরের উদাহরণে, আমি github.actor ব্যবহার করেছি ওয়ার্কফ্লো শুরু করা অ্যাকাউন্টের ব্যবহারকারীর নাম ইনপুট করার জন্য প্রসঙ্গ পরিবর্তনশীল। ইমেলটি একইভাবে ডিফল্ট noreply ব্যবহার করে কনফিগার করা হয়েছে GitHub ইমেল ঠিকানা।

ইভেন্ট ডেটা প্রদর্শন করা হচ্ছে

নভেম্বর 6, 2019 সংশোধন:একটি পেজ সাইট বিল্ড ট্রিগার করার জন্য GitHub অ্যাকশনগুলির একটি ব্যক্তিগত অ্যাক্সেস টোকেন প্রয়োজন৷

আপনি যদি ডিফল্ট secrets.GITHUB_TOKEN সহ GitHub পৃষ্ঠাগুলি ব্যবহার করেন ভেরিয়েবল এবং সাইট জেনারেটর ছাড়া, ওয়ার্কফ্লোতে রিপোজিটরিতে পরিবর্তনগুলি পুশ করা শুধুমাত্র রিপোজিটরি ফাইল আপডেট করবে। গিটহাব পেজ বিল্ড একটি ত্রুটির সাথে ব্যর্থ হবে, "আপনার সাইট তৈরিতে সমস্যা হচ্ছে:পৃষ্ঠা তৈরি ব্যর্থ হয়েছে।"

একটি পেজ সাইট বিল্ড ট্রিগার করার জন্য অ্যাকশন সক্রিয় করতে, আপনাকে একটি ব্যক্তিগত অ্যাক্সেস টোকেন তৈরি করতে হবে। এই টোকেনটি রিপোজিটরি সেটিংসে একটি গোপন হিসাবে সংরক্ষণ করা যেতে পারে এবং ডিফল্ট secrets.GITHUB_TOKEN এর জায়গায় ওয়ার্কফ্লোতে পাস করা যেতে পারে। পরিবর্তনশীল আমি এই পোস্টে অ্যাকশন এনভায়রনমেন্ট এবং ভেরিয়েবল সম্পর্কে আরও লিখেছি।

একটি ব্যক্তিগত অ্যাক্সেস টোকেন ব্যবহারের সাথে, অ্যাকশন ওয়ার্কফ্লো দ্বারা সূচিত একটি পুশ পেজ সাইট আপডেট করবে। আপনি আমার গেস্টবুকে একটি মন্তব্য রেখে নিজের জন্য এটি দেখতে পারেন! মন্তব্য তৈরির ইভেন্টটি ওয়ার্কফ্লোকে ট্রিগার করে, যা গেস্টবুক পৃষ্ঠাটি চালানো এবং আপডেট করতে প্রায় 30 সেকেন্ড থেকে এক মিনিট সময় নেয়।

যেখানে পরিবর্তনগুলি প্রকাশ করার জন্য একটি সাইট বিল্ড প্রয়োজনীয়, যেমন Hugo ব্যবহার করার সময়, একটি অ্যাকশনও এটি করতে পারে। যাইহোক, অনিচ্ছাকৃত লুপ তৈরি এড়াতে, একটি অ্যাকশন ওয়ার্কফ্লো অন্যটি ট্রিগার করবে না। পরিবর্তে, একটি মেকফাইল দিয়ে সাইট তৈরির প্রক্রিয়াটি পরিচালনা করা অত্যন্ত সুবিধাজনক, যেটি যেকোন ওয়ার্কফ্লো তখন চালাতে পারে। আপনার ওয়ার্কফ্লো কাজের চূড়ান্ত ধাপ হিসেবে মেকফাইল চালানো যোগ করুন, যেখানে প্রয়োজন সেখানে রিপোজিটরি টোকেন সহ:

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

এটি নিশ্চিত করে যে আপনার কর্মপ্রবাহের চূড়ান্ত ধাপ আপডেট করা সাইট তৈরি এবং স্থাপন করে।

আর কোন ইভেন্ট ডেটা দিগন্ত নেই

গিটহাব অ্যাকশনগুলি ইভেন্ট ডেটা ক্যাপচার এবং ব্যবহার করার একটি সুন্দর উপায় সরবরাহ করে যাতে এটি কেবল গিটহাবের মধ্যেই উপলব্ধ না হয়। সম্ভাবনাগুলি শুধুমাত্র আপনার কল্পনা হিসাবে সীমিত! এখানে এমন কিছু ধারনা রয়েছে যা আমাদের তৈরি করতে দেয়:

একটি সর্বজনীন-মুখী সমস্যা বোর্ড, যেখানে GitHub অ্যাকাউন্ট ছাড়া গ্রাহকরা প্রকল্পের সমস্যাগুলি দেখতে এবং প্রতিক্রিয়া দিতে পারেন৷
যেকোন রিপোজিটরির জন্য নতুন সমস্যা, মন্তব্য বা PR-এর স্বয়ংক্রিয়ভাবে আপডেট হওয়া RSS ফিড।
স্ট্যাটিক সাইটগুলির জন্য একটি মন্তব্য সিস্টেম, একটি ইনপুট পদ্ধতি হিসাবে GitHub সমস্যা মন্তব্যগুলি ব্যবহার করে৷
৯০ দশকের একটি অসাধারণ গেস্টবুক পেজ।

আমি কি উল্লেখ করেছি যে আমি একটি 90 এর গেস্টবুক পৃষ্ঠা তৈরি করেছি? আমার অভ্যন্তরীণ-জিওসিটিস-নার্ড একটু উত্তেজিত।