GitHub Actions-এ exact count আর নেই—২,৫০০ পেরোলেই script বদলান

২৫ সেপ্টেম্বর ২০২৬-এর GitHub-এর পরিবর্তন ঘোষণায় জানানো হয়েছে, GitHub Actions-এ workflow, event, status, branch বা actor দিয়ে খোঁজার সময় ২,৫০০-এর বেশি run মিললে API ও ওয়েব ইন্টারফেস নির্ভুল মোটের বদলে ‘2,500+’ দেখায়। পরিবর্তনটি github.com ও GitHub Enterprise Cloud-এ ধাপে ধাপে চালু হচ্ছে। ফলে বড় অনুসন্ধানের গণনা ধরে রপ্তানির পাতা নির্ধারণ করা স্ক্রিপ্ট বদলাতে হবে।

বড় workflow history query অসম্পূর্ণ দেখানোর পেছনে দুটি আলাদা সীমা আছে: প্রদর্শিত মোটের নির্ভুলতা এবং একটি filtered search থেকে সংগ্রহযোগ্য ফলের সংখ্যা। UNDERCODE NEWS-এর প্রতিবেদনেও বড় অনুসন্ধানে গণনার পরিবর্তন এবং পাতা ধরে ফল সংগ্রহ চালু থাকার কথা বলা হয়েছে। অডিটে সব উপলব্ধ run দরকার হলে বিস্তৃত অনুসন্ধানের সংখ্যাকে চূড়ান্ত মোট না ধরে একই filter-সহ ছোট সময়পরিসরে অনুসন্ধান চালাতে হবে।

‘2,500+’ গণনা, রপ্তানির পরিমাণ নয়

‘2,500+’ মানে মিল পাওয়া run সীমা পেরিয়েছে; ঠিক কতটি মিলেছে, তা এই চিহ্ন বলে না। GitHub-এর ব্যাখ্যা অনুযায়ী, বড় অনুসন্ধানে আগের নির্ভুল গণনার চেষ্টা প্রায়ই সময়সীমা অতিক্রম করত। সে ক্ষেত্রে ফেরত আসা সংখ্যাটি প্রকৃত মোটের বদলে অনুসন্ধান থামার আগে পাওয়া রেকর্ডের সংখ্যা হতে পারত। নতুন চিহ্ন সেই আপাত নির্ভুল সংখ্যার ওপর নির্ভর করার সুযোগ সরিয়ে দেয়।

GitHub-এর workflow-run REST নথি অনুযায়ী, নির্দিষ্ট filter ব্যবহার করা অনুসন্ধান থেকে সর্বোচ্চ ১,০০০টি ফল পাওয়া যায়; প্রতি পাতায় সর্বোচ্চ ১০০টি ফল চাওয়া যায় এবং created দিয়ে তৈরির সময়ের পরিসর বেঁধে দেওয়া যায়। তাই ২,৫০০-এর বেশি মিল দেখানো অনুসন্ধান থেকে পাতা উল্টে সব run পাওয়া যাবে, এমন নয়। গণনার সীমা এবং সংগ্রহযোগ্য ফলের সীমা এক জিনিস নয়।

পুরোনো অটোমেশনে এই পার্থক্য দুইভাবে ভুল ফল দিতে পারে। মোট গণনা দেখে পাতার সংখ্যা ঠিক করা প্রক্রিয়া সীমা পেরোনো চিহ্নকে পূর্ণসংখ্যা ধরে ফেলতে পারে। আবার শেষ পাওয়া পাতাকেই ইতিহাসের শেষ পাতা মনে করলে একই অনুসন্ধানের সংগ্রহসীমার বাইরে থাকা run বাদ যাবে। রিপোর্টে তাই অনুসন্ধান কত মিলের ইঙ্গিত দিয়েছে এবং বাস্তবে কত স্বতন্ত্র run সংরক্ষিত হয়েছে, তা পৃথক তথ্য হিসেবে রাখতে হবে।

তারিখভিত্তিক খণ্ডে পূর্ণ ফল সংগ্রহের ছদ্মকোড

রপ্তানির মূল নিয়ম হলো repository, workflow এবং প্রয়োজনীয় অন্য filter অপরিবর্তিত রেখে শুধু created সময়পরিসর ছোট করা। প্রথমে দিনভিত্তিক খণ্ড নেওয়া যেতে পারে, তবে একটি ব্যস্ত দিনও সংগ্রহসীমা ছাড়াতে পারে। তাই খণ্ডের দৈর্ঘ্য স্থির করে নিরাপদ ধরে নেওয়ার বদলে প্রতিটি খণ্ডের ফল দেখে প্রয়োজন হলে সেটিকে আরও ভাগ করতে হবে।

নিচের ছদ্মকোডটি একটি বাস্তবায়ন-পদ্ধতির রূপরেখা; এটি চালিয়ে পাওয়া পরীক্ষার ফল নয়। এর উদ্দেশ্য হলো কোনো সময়খণ্ড অসম্পূর্ণ থাকলে সেটিকে সফল রপ্তানি হিসেবে না দেখানো।

1. collect(শুরু, শেষ): নির্দিষ্ট repository ও filter-এর সঙ্গে created পরিসর যোগ করে প্রথম পাতা আনুন। রপ্তানির শেষ সময়টি কাজ শুরুর আগেই স্থির করুন, যাতে চলতে চলতে তৈরি নতুন run একই অডিটের সীমানা বদলে না দেয়।
2. ফেরত আসা মোট সংখ্যা সীমা-পেরোনো চিহ্ন হলে, নির্ভুল গণনা সংগ্রহসীমায় পৌঁছালে, অথবা পাতার ফল দেখে খণ্ডটি সম্পূর্ণ পাওয়া গেছে বলে নিশ্চিত হওয়া না গেলে collect চালানোর আগে সময়পরিসর দুটি ছোট খণ্ডে ভাগ করুন। শুধু ‘2,500+’ দেখা পর্যন্ত অপেক্ষা করবেন না: তার নিচের বড় অনুসন্ধানও সংগ্রহসীমা ছাড়াতে পারে।
3. নিরাপদ খণ্ডে প্রতিটি পাতা সংগ্রহ করুন। কোনো অনুরোধ ব্যর্থ হলে কিংবা প্রত্যাশিত পাতা পাওয়া না গেলে খণ্ডটিকে অসম্পূর্ণ রাখুন; আগের পাতাগুলো পাওয়া গেছে বলেই পুরো খণ্ড সফল চিহ্নিত করবেন না। পরে পুনরায় চালানোর সুবিধার জন্য খণ্ডের সীমানা ও সংগ্রহের অগ্রগতি সংরক্ষণ করুন।
4. সম্পূর্ণ খণ্ডের run-গুলো repository ও run-এর স্বতন্ত্র id দিয়ে একত্র করুন। পুনরায় চালানো খণ্ড বা সীমানায় ওভারল্যাপের কারণে একই run ফিরে এলে সেটি একবারই গণনা করুন। সব নির্ধারিত খণ্ড সম্পূর্ণ হওয়ার পরেই সংরক্ষিত স্বতন্ত্র run-এর মোট প্রকাশ করুন।

সময়খণ্ডের সীমানাও পদ্ধতির অংশ। পাশাপাশি দুটি পরিসরের মাঝে ফাঁক থাকলে সীমানায় তৈরি run বাদ পড়তে পারে; ওভারল্যাপ থাকলে একই run দুবার ফিরতে পারে। নির্দিষ্ট সীমানা ব্যবহার এবং id দিয়ে পুনরাবৃত্তি সরানো একসঙ্গে এই ঝুঁকি সামলায়। কোনো ক্ষুদ্র খণ্ডও সম্পূর্ণ সংগ্রহ করা না গেলে অডিটের ফলকে অসম্পূর্ণ হিসেবে দেখানোই সঠিক অবস্থা।

ড্যাশবোর্ড ও অ্যালার্টে কী বদলাবে

ড্যাশবোর্ডে ‘2,500+’কে সাধারণ পূর্ণসংখ্যায় বদলে আগের দিনের গণনা থেকে বিয়োগ করা যাবে না। এটি নির্দিষ্ট মোট নয়, সীমা পেরোনোর অবস্থা। সঠিক সময়ভিত্তিক মোট প্রয়োজন হলে সম্পূর্ণ সংগ্রহ করা খণ্ডগুলোর স্বতন্ত্র run গুনতে হবে; আর বিস্তৃত অনুসন্ধানের ফল দেখালে সেটিকে সীমা-পেরোনো গণনা হিসেবেই চিহ্নিত রাখতে হবে।

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

বর্তমানে নিশ্চিত পরিবর্তনটি বড় filtered workflow-run অনুসন্ধানের গণনায়; পাতাভিত্তিক ফল পাওয়ার পৃথক সীমাও বহাল আছে। নির্দিষ্ট অডিটের নির্ভুল মোট তাই বিস্তৃত অনুসন্ধানের প্রদর্শিত সংখ্যা থেকে উদ্ধার করা যায় না। নির্বাচিত সময়পরিসরের সব খণ্ড সম্পূর্ণ সংগ্রহ করে স্বতন্ত্র run গণনাই সেই মোট তৈরির ভিত্তি।

আরও পড়ুন:

• GitHub Actions-এ নতুন ডিফল্ট বাধা—২ নভেম্বর ভাঙতে পারে কিছু workflow
• GitHub Copilot থেকে ছয় মডেল যাচ্ছে—১৯ অক্টোবরের আগে workflow বদলান
• Claude API-তে 429 এড়ান—token count আর cache-এর হিসাব আগে করুন