GitHub Actions-এ expired artifact অদৃশ্য—প্রমাণ থাকবে শুধু log-এ

GitHub-এর ২৪ সেপ্টেম্বর ২০২৬-এর পরিবর্তন বিজ্ঞপ্তি অনুযায়ী, মেয়াদোত্তীর্ণ GitHub Actions artifact আর workflow run summary-তে দেখা যায় না। Repository-র artifact তালিকা এবং নির্দিষ্ট artifact পাওয়ার REST API endpoint-ও সেটি ফেরায় না। কোন run artifact তৈরি করেছিল, সেই তথ্য সংশ্লিষ্ট run-এর log-এ থাকতে পারে—যত দিন log সংরক্ষিত আছে।

jls-এর প্রযুক্তি সংকলন ও ২৪ সেপ্টেম্বর ২০২৬-এর এই পরিবর্তনে run summary ও REST API থেকে মেয়াদোত্তীর্ণ artifact বাদ পড়ার কথা নথিবদ্ধ করেছে। ফলে পুরোনো run-এ artifact না দেখা, অথবা ওই API-তে তার record না পাওয়া, run-টি কখনো artifact তৈরি করেনি—এমন প্রমাণ নয়। পুরোনো build, audit trail বা deployment যাচাইয়ের ক্ষেত্রে এই পার্থক্যটি জরুরি।

মেয়াদোত্তীর্ণ artifact কেন আর দেখা যাচ্ছে না

আগে artifact-এর ফাইল storage থেকে মুছে যাওয়ার পরও run summary-তে ‘Expired’ চিহ্নসহ তার entry থাকতে পারত। ওই entry দেখে ফাইল এখনও রাখা আছে বা তার জন্য storage charge চলছে কি না, তা নিয়ে বিভ্রান্তি তৈরি হতো। এখন মেয়াদ শেষ হলে entry-টিও উল্লিখিত দৃশ্য ও API response থেকে বাদ যায়। পরিবর্তনটি অতীতের upload মুছে দেওয়ার নতুন নির্দেশ নয়; মেয়াদোত্তীর্ণ upload কীভাবে দেখানো হবে, সেটিই বদলেছে।

এর ফলে run summary-র artifact অংশ বর্তমানে পাওয়া যায় এমন ফাইল শনাক্ত করতে সাহায্য করে, কিন্তু কোনো run অতীতে যত artifact তৈরি করেছে তার পূর্ণ তালিকা হিসেবে ব্যবহার করা যায় না। একই সীমা repository-র artifact তালিকা এবং নির্দিষ্ট artifact পাওয়ার endpoint-এর ক্ষেত্রেও প্রযোজ্য। ঘোষণায় উল্লেখ নেই এমন সব endpoint-এ ঠিক একই আচরণ হবে, এমন সিদ্ধান্ত এই তথ্য থেকে টানা যায় না।

যে script আগের API response থেকে ‘expired’ record সংগ্রহ করে historical report বানাত, সেটি এখন পুরোনো upload বাদ দিতে পারে। তবে একটি অনুপস্থিত response দেখেই upload ব্যর্থ হয়েছিল বা artifact-এর মেয়াদই শেষ হয়েছে—কোনোটিই নিশ্চিত বলা যায় না। অনুসন্ধানে সংশ্লিষ্ট run, তার log এবং আগে সংরক্ষিত record মিলিয়ে দেখতে হবে; API তালিকা এখন একা পূর্ণ ইতিহাস দেয় না।

Run log-এ কী পাওয়া যেতে পারে

মেয়াদ শেষ হওয়ার পরে GitHub-এর ভেতরে artifact-এর নাম বা উৎপাদনের সূত্র খোঁজার জায়গা হলো সংশ্লিষ্ট workflow run-এর log। Upload ধাপের তথ্য এখনও থাকলে কোন run-এ কোন artifact তৈরি হয়েছিল, তা শনাক্ত করা যেতে পারে। শিরোনামের ‘শুধু log-এ’ কথাটি এই অবশিষ্ট GitHub পথকেই বোঝায়; দলের আগে রাখা বাহ্যিক record থাকলে সেটিও প্রমাণের উৎস।

Log-এ upload-এর উল্লেখ পাওয়া এবং মূল artifact ফাইল হাতে পাওয়া এক বিষয় নয়। ফাইল storage থেকে মুছে গেলে log পড়ে তার বিষয়বস্তু পুনরুদ্ধার করা যায় না। একইভাবে log-এ একটি নাম পাওয়া গেলেও সেই ফাইল পরে কোন release বা পরিবেশে deploy হয়েছিল, তা আলাদা deployment record ছাড়া প্রতিষ্ঠিত হয় না। উৎপাদন ও deployment দুটি পৃথক ঘটনা, তাই তাদের প্রমাণের যোগসূত্রও পৃথকভাবে রাখতে হয়।

Log-ও স্থায়ী archive নয়। সংশ্লিষ্ট log আর সংরক্ষিত না থাকলে GitHub-এর ওই পথ থেকে নাম উদ্ধার করার নিশ্চয়তা থাকে না। তখন আগে রাখা release record, deployment record বা বাহ্যিক manifest সহায়ক হতে পারে। কিন্তু মেয়াদ শেষ হওয়ার পরে অনুমান করে artifact-এর নাম, ID বা digest লেখা হলে সেটি run চলার সময় ধরা তথ্যের সমমানের প্রমাণ হয় না।

Retention, artifact ID ও URL-এর সীমা

actions/upload-artifact-এর নথি অনুযায়ী, upload-এর সময় retention-days দিয়ে artifact-এর সংরক্ষণকাল নির্ধারণ করা যায়। সফল upload-এর output-এ artifact ID, URL এবং artifact-এর SHA-256 digest পাওয়া যায়। URL শুধু artifact-এর মেয়াদ থাকা পর্যন্ত কার্যকর; artifact, run বা repository মুছে গেলেও সেটি অকার্যকর হয়। তাই URL রেখে দেওয়া ফাইলের দীর্ঘমেয়াদি কপি রাখার সমতুল্য নয়।

Artifact ID নির্দিষ্ট upload শনাক্ত করার জন্য মূল্যবান। একই নাম বিভিন্ন run-এ আবার ব্যবহার হতে পারে, আর একটি artifact বদলে নতুন করে upload করলে নতুন ID তৈরি হতে পারে। ফলে কেবল নামের চেয়ে ID-এর সঙ্গে run-এর পরিচয় ও commit ধরে রাখা ইতিহাস মিলিয়ে দেখতে বেশি কার্যকর। তবু মেয়াদোত্তীর্ণ artifact-এর ID হাতে থাকলেই API থেকে মুছে যাওয়া ফাইল ফেরত পাওয়া যাবে না।

Digest-ও কোন artifact-এর কথা বলা হচ্ছে তা মিলিয়ে দেখার উপাদান, ফাইলের বিকল্প নয়। সংরক্ষিত কপির সঙ্গে digest যাচাই করতে হলে সেই কপি আগে থেকেই থাকতে হবে। Artifact-এর জন্য workflow-তে সংক্ষিপ্ত মেয়াদ দেওয়া থাকলে তার ফাইল log-এর আগেই হারিয়ে যেতে পারে; আবার log-ও একসময় অনুপলব্ধ হতে পারে। তাই প্রয়োজনীয় প্রমাণ কত দিন রাখতে হবে, সেটি GitHub-এ বর্তমানে কী দেখা যাচ্ছে তার ওপর ছেড়ে দেওয়া যায় না।

মেয়াদ শেষ হওয়ার আগে audit trail কীভাবে ধরে রাখা যায়

এই পরিবর্তনের জন্য একটি ছোট বাহ্যিক manifest ব্যবহারিক সমাধান। এটি GitHub-এর নতুন কোনো সুবিধা নয়, দলের নিজস্ব রেকর্ড: upload সফল হওয়ার সময় তার পরিচয় এবং পরের deployment-এর সম্পর্ক ধরে রাখার ব্যবস্থা। উদ্দেশ্য হলো পরে artifact API-তে record না মিললেও অতীতে কী তৈরি হয়েছিল, সে দাবির ভিত্তি অক্ষত রাখা।

1. Upload সফল হলে manifest-এ repository, workflow, run, commit, artifact-এর নাম এবং পাওয়া artifact ID লিখুন। এতে একই নামের পৃথক run-এর upload গুলিয়ে যাওয়ার ঝুঁকি কমে।
2. পাওয়া গেলে artifact digest এবং নির্ধারিত retention-ও একই record-এ রাখুন। Digest পরিচয় যাচাইয়ে কাজে লাগে; মেয়াদোত্তীর্ণ ফাইল ফিরিয়ে আনে না।
3. Deployment record-এ কোন manifest entry থেকে কোন release বা পরিবেশে ফাইল পাঠানো হয়েছে, সেই সম্পর্ক ধরুন। শুধু upload record দিয়ে deployment-এর দাবি প্রমাণিত হয় না।
4. নিজস্ব audit নীতিতে যত দিন দরকার, তত দিন manifest এবং প্রয়োজনীয় log বা artifact-এর অনুমোদিত কপি GitHub-এর মেয়াদের বাইরে রাখুন। কে record বদলাতে পারে, সেই নিয়ন্ত্রণও প্রমাণের বিশ্বাসযোগ্যতার অংশ।

পুরোনো artifact-এর ক্ষেত্রে এই রীতি পরে গিয়ে হারানো ফাইল উদ্ধার করবে না। তখন যে log, deployment record বা metadata এখনও পাওয়া যায়, সেগুলো দিয়ে সীমিত ইতিহাস পুনর্গঠন করতে হবে। কোনো নাম, digest বা deployment-এর যোগসূত্র না মিললে সেই ঘাটতি record-এ স্পষ্ট রাখা প্রয়োজন। অনুপস্থিত অংশ পূরণ করতে অনুমান বসালে audit trail দেখতে সম্পূর্ণ হলেও তার প্রমাণমূল্য বাড়ে না।

Storage bill ও ঐতিহাসিক প্রমাণ আলাদা হিসাব

মেয়াদোত্তীর্ণ entry অদৃশ্য হওয়ার পরিবর্তনটি retention setting বা billing policy বদলায়নি। আগে ‘Expired’ চিহ্ন দেখা যেত বলে ফাইল তখনও storage-এ ছিল, এমন সিদ্ধান্ত নেওয়া যেত না; এখন entry না দেখেও আগের storage ব্যবহার বা বিলের অঙ্ক নির্ণয় করা যায় না। Billing যাচাইয়ের জন্য প্রযোজ্য usage record দেখতে হবে। Artifact তালিকা মূলত বর্তমানে ফেরত পাওয়া record দেখায়, অতীতের charge-এর খতিয়ান নয়।

Historical evidence-এর প্রশ্ন আলাদা: কোন run কী upload করেছিল, এবং তার মধ্যে কোনটি deploy হয়েছিল। মেয়াদোত্তীর্ণ artifact-এর ক্ষেত্রে run log থাকলে প্রথম প্রশ্নের সূত্র মিলতে পারে; দ্বিতীয় প্রশ্নের জন্য deployment-এর নিজস্ব record দরকার। বর্তমান ঘোষণায় এই দুই ইতিহাসের স্থায়ী archive দেওয়ার কথা নেই। তাই log-ও আর না থাকলে আগে সংরক্ষিত manifest ও অন্য নির্ভরযোগ্য record-ই যাচাইয়ের ভিত্তি হবে।

আরও পড়ুন:

• GitHub Actions cache-mode বসান—একটি ভুলে cache poisoning ফিরতে পারে
• GitHub Actions-এ নতুন ডিফল্ট বাধা—২ নভেম্বর ভাঙতে পারে কিছু workflow
• GitHub Actions cache-এ চার স্তরের অনুমতি—ভুল write-এ ঝুঁকি ফিরবে