নেটওয়ার্কের বাইরে Python wheel তৈরি করুন, ভেতরে প্রকাশ করুন

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

যেখানে সোর্স আগে থেকেই আছে সেখানেই বিল্ড করুন

যে জবের কাছে ইতিমধ্যে সোর্স, টুলচেইন ও টেস্ট স্যুট আছে, সেই জবেই বিল্ড চালান। প্রাইভেট রিপোজিটরির ব্যাপারে এমন কিছু নেই যা ওই জবকে সেখানে পৌঁছাতে বাধ্য করে। প্রজেক্ট যে এনভায়রনমেন্ট ইতিমধ্যে ব্যবহার করে সেখানেই বিল্ড ফ্রন্টএন্ড ইনস্টল করুন, তারপর প্রজেক্ট দুটি ডিস্ট্রিবিউশন ফরম্যাটই পাঠালে দুটিই তৈরি করুন।

python -m build --sdist --wheel --outdir dist
python -m twine check dist/*

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

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

বাইট সরান, পুনরায় বিল্ডের নির্দেশ নয়

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

ডিস্ট্রিবিউশন ফাইলগুলো আপনার CI প্ল্যাটফর্ম যে আর্টিফ্যাক্ট স্টোর দেয় সেখানে আপলোড করুন, আর অভ্যন্তরীণ জবকে ব্রাঞ্চের নাম নয়, ঠিক সেই আর্টিফ্যাক্টের রেফারেন্স দিন।

sha256sum dist/*.whl dist/*.tar.gz
# keep the digests beside the run id in the artifact description

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

আপলোডের আগে ভেতরে যাচাই করুন

অভ্যন্তরীণ জব শুরু হয় এটা যাচাই করে যে এটি যে ফাইল পেয়েছে সেটিই অনুমোদিত ফাইল। ডাইজেস্টগুলো বিল্ড জবের রেকর্ডের সঙ্গে মেলান, যা কিছু এসেছে তা থেকে আবার গণনা করা কোনো মানের সঙ্গে নয়।

sha256sum -c digests.txt
python -m twine check dist/*

তারপর মেটাডেটা পড়ুন। প্যাকেজের নাম, ভার্সন এবং ঘোষিত নির্ভরতাগুলো আপনার অনুমোদিত পর্যালোচনার সঙ্গে মিলতে হবে। যে wheel-এর নাম ঠিক দেখায় কিন্তু নির্ভরতার পিন বদলে গেছে, সেটি একই লেবেল পরা ভিন্ন প্যাকেজ। মেটাডেটা সরে গেলে আর্টিফ্যাক্টটিকে অননুমোদিত ধরুন এবং কোন বিল্ড এটি তৈরি করেছে তা খুঁজে বের করুন।

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

ডুপ্লিকেট ভার্সনের উত্তর সামলান

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

বিদ্যমান ভার্সন মানে হতে পারে আগের আপলোড সফল হয়েছিল আর উত্তরটি হারিয়ে গেছে, অথবা কেউ একই নম্বরের নিচে ভিন্ন কনটেন্ট প্রকাশ করেছে।

ভার্সনটি মুছবেন না, এবং ত্রুটি এড়াতে নতুন নম্বর বানাবেন না। সংরক্ষিত কনটেন্ট গ্রহণযোগ্য কি না তা রিলিজ মালিকের সঙ্গে ঠিক করুন, তারপর ফলাফল লিপিবদ্ধ করুন। কনটেন্ট আলাদা হলে এটি ভার্সনিংয়ের সমস্যা, পাইপলাইনের সমস্যা নয়।

আপলোড ক্রেডেনশিয়াল এক পাশে রাখুন

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

কোন অভ্যন্তরীণ ওয়ার্কফ্লো প্রকাশক চালু করতে পারবে তাও সীমিত করুন। আবশ্যক অনুমোদনসহ ম্যানুয়াল ট্রিগার রিলিজের জন্য যুক্তিসঙ্গত ডিফল্ট; যেকোনো ব্রাঞ্চে পুশ নয়।

সম্পন্ন রিলিজের পিছনে তিনটি জিনিস রাখা উচিত: ডিস্ট্রিবিউশন ফাইলগুলো, সোর্স রিভিশনসহ তাদের ডাইজেস্ট, এবং একই ভার্সন দেখানো একটি রিপোজিটরি রেকর্ড।