এই ওয়ার্কিং ডকুমেন্টটি GitHub Actions ব্যবহারের জন্য বেস্ট প্র্যাকটিসের একটি সংগ্রহ হিসেবে কাজ করে।
আপনার কোনো পরামর্শ বা সংযোজন থাকলে, GitHub-এ একটি পুল রিকোয়েস্ট খুলুন!
বেস্ট প্র্যাকটিসের সংগ্রহ
ওয়ার্কফ্লোর জন্য টাইমআউট সেট করুন
ডিফল্টভাবে, GitHub Actions কোনো ওয়ার্কফ্লো ৬ ঘণ্টার মধ্যে শেষ না হলে তা বন্ধ করে দেয়।
অনেক ওয়ার্কফ্লোর শেষ হতে এর চেয়ে অনেক কম সময়ই লাগে, কিন্তু কখনও কখনও অপ্রত্যাশিত এরর ঘটে, বা কোনো জব আটকে যায়, আর ওয়ার্কফ্লো রানটি শুরু হওয়ার ৬ ঘণ্টা পর বন্ধ হয়ে যায়।
তাই ছোট একটি টাইমআউট নির্দিষ্ট করার পরামর্শ দেওয়া হয়।
আদর্শ টাইমআউট কোনটি, তা নির্দিষ্ট ওয়ার্কফ্লোর উপর নির্ভর করে, তবে Exercism রিপোগুলোতে ব্যবহৃত ওয়ার্কফ্লোগুলোর জন্য সাধারণত ৩০ মিনিটই যথেষ্টের চেয়ে বেশি।
এতে নিচের সুবিধাগুলো পাওয়া যায়:
- 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-এর মাধ্যমে) পিন করুন, ব্রাঞ্চ বা ট্যাগে নয়।
এতে নিশ্চিত হয় যে প্রতিবার একই কোড রান হবে, যা ব্রাঞ্চ বা ট্যাগে পিন করলে নিশ্চিত থাকে না।
এর দুটি সুবিধা আছে:
- এটি আপনার বিল্ডকে স্থিতিশীল করে তোলে
- এটি কোনো আক্রমণকারীকে ব্রাঞ্চ/ট্যাগ বদলে ক্ষতিকর কোডের দিকে নির্দেশ করাতে বাধা দেয়
এই নিয়মের একমাত্র ব্যতিক্রম হতে পারে আমাদের (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/') }}
থার্ড-পার্টি নোটিশ
উপরের উদাহরণটি PkgTemplates.jl-এর CI ওয়ার্কফ্লো অবলম্বনে তৈরি, যা MIT লাইসেন্সের অধীনে প্রকাশিত:
MIT লাইসেন্স
Copyright (c) 2017-2020 Chris de Graaf, Invenia Technical Computing Corporation
এতদ্বারা যে কেউ এই সফটওয়্যার ও সংশ্লিষ্ট ডকুমেন্টেশন ফাইলগুলোর (এরপর "Software") একটি কপি পেলে, তাকে বিনামূল্যে, কোনো বাধা ছাড়াই অনুমতি দেওয়া হচ্ছে যে সে Software-টি ব্যবহার, কপি, পরিবর্তন, একত্রীকরণ, প্রকাশ, বিতরণ, সাবলাইসেন্স প্রদান ও বিক্রি করতে পারবে, যার মধ্যে ওই অধিকারগুলো অন্তর্ভুক্ত, তবে এগুলোতেই সীমাবদ্ধ নয়, এবং যাঁদের কাছে Software-টি সরবরাহ করা হয়, তাঁদেরও তা করার অনুমতি দিতে পারবে, তবে নিচের শর্ত সাপেক্ষে:
Software-এর সব কপি বা উল্লেখযোগ্য অংশে উপরের কপিরাইট নোটিশ এবং এই অনুমতিপত্রটি অন্তর্ভুক্ত থাকতে হবে।
SOFTWARE-টি "AS IS" ভিত্তিতে দেওয়া হচ্ছে, কোনো ধরনের ওয়ারেন্টি ছাড়াই, তা প্রকাশ্য হোক বা অন্তর্নিহিত, যার মধ্যে বাণিজ্যিক উপযোগিতা, নির্দিষ্ট উদ্দেশ্যে উপযুক্ততা এবং অধিকার লঙ্ঘন না করার নিশ্চয়তা অন্তর্ভুক্ত, তবে এগুলোতেই সীমাবদ্ধ নয়। কোনো অবস্থাতেই লেখক বা কপিরাইট ধারকরা কোনো দাবি, ক্ষতি বা অন্য কোনো দায়ের জন্য দায়ী থাকবেন না, তা চুক্তি, অন্যায়কর্ম বা অন্য কোনো উপায়ে উদ্ভূত হোক না কেন, এবং তা SOFTWARE বা তার ব্যবহার কিংবা অন্য কোনো প্রয়োগ থেকে উদ্ভূত হোক।
কোন ট্রিগার সত্যিই দরকার, ভেবে দেখুন
"Security hardening for GitHub Actions" গাইডটি পড়ুন
উপরে বলা প্র্যাকটিসগুলো কোনোভাবেই সম্পূর্ণ নয়।
GitHub Actions নিরাপদে ব্যবহারের জন্য ভালো সিকিউরিটি প্র্যাকটিসের একটি পূর্ণাঙ্গ গাইডের জন্য GitHub-এর সিকিউরিটি গাইড দেখুন।
ওয়ার্কফ্লো চেকলিস্ট
কোনো ওয়ার্কফ্লো বেস্ট প্র্যাকটিস মেনে চলছে কি না, তা যাচাই করতে নিচের চেকলিস্টটি ব্যবহার করতে পারেন।
চেকলিস্টটি সম্পূর্ণ হওয়ার উদ্দেশ্যে তৈরি নয়, বরং এটি সবচেয়ে গুরুত্বপূর্ণ বিষয়গুলোর দিকে মনোযোগ দেয়।
কপি-পেস্ট করার মতো ভার্সন, যেমন PR-এর জন্য
