Dependabot-এর private package access-এ PAT লাগবে না—অনুমতি তবু নিজে দিতে হবে
GitHub ৮ সেপ্টেম্বর ২০২৬-এ Dependabot-এর জন্য private GitHub Packages থেকে personal access token বা PAT ছাড়াই dependency পড়ার সুবিধা পুনরায় চালু করেছে। GitHub-এর আনুষ্ঠানিক changelog জানায়, Dependabot-এর GITHUB_TOKEN এখন packages: read permission চাইতে পারে; তবে package settings-এর Manage Actions access থেকে যে repository-তে Dependabot চলে, সেটিকে আগে Read access দিতে হবে।
অর্থাৎ নির্দিষ্ট GitHub-hosted private package-এর জন্য পুরোনো PAT সরানো যাবে, কিন্তু অনুমতি স্বয়ংক্রিয়ভাবে বাড়বে না। ৮ সেপ্টেম্বরের SourceFeed-এর প্রতিবেদনেও পুনরায় চালুর একই অবস্থা, repository-ভিত্তিক grant এবং automatic credential-কে fallback রাখার সংশোধনটি উল্লেখ করা হয়েছে।
Automatic GITHUB_TOKEN কেবল fallback
Dependabot কোনো dependency আনতে *.pkg.github.com বা ghcr.io-তে গেলে job-এর GITHUB_TOKEN দিয়ে authentication করতে পারে। সংশ্লিষ্ট package যদি Manage Actions access-এর মাধ্যমে consumer repository-কে অনুমতি দিয়ে রাখে, তবে Dependabot সেই grant ব্যবহার করে package পড়বে। GitHub Actions workflow-এর জন্য ব্যবহৃত একই package-to-repository access model এখানে প্রযোজ্য।
Fallback হওয়াটিই পুনরায় চালু সংস্করণের গুরুত্বপূর্ণ সীমা। dependabot.yml-এ থাকা explicit registry credential এবং package manager-এর স্বাভাবিক registry routing আগে কার্যকর হবে; automatic GitHub Packages credential সেগুলোকে অতিক্রম করে প্রথম পছন্দে পরিণত হবে না। তাই ইচ্ছাকৃত npm scope, registry URL বা replaces-base configuration শুধু নতুন authentication এসেছে বলে মুছে ফেলার প্রয়োজন নেই।
এই অগ্রাধিকার আগের সমস্যার সরাসরি সংশোধন। GitHub প্রথমবার ২৩ জুন ২০২৬-এ সুবিধাটি চালুর পর সাময়িকভাবে rollback করেছিল, কারণ conflict-এর ফলে কিছু npm update job public package-ও GitHub Packages দিয়ে resolve করার চেষ্টা করছিল। ৮ সেপ্টেম্বরের সংস্করণে automatic credential fallback হওয়ায় explicit credential ও স্বাভাবিক routing-এর precedence বজায় থাকে।
Manage Actions access কোথায় দিতে হবে
PAT না থাকলেও Dependabot কোনো account বা organization-এর সব private package দেখতে পাবে না। প্রয়োজনীয় package-এর settings page খুলে Manage Actions access অংশে Dependabot চালানো repository যোগ করতে হবে এবং access level হিসেবে Read বেছে নিতে হবে। Package organization-এর হলে organization-এর Packages tab, আর personal account-এর হলে সেই account-এর Packages tab থেকে package settings-এ যাওয়া যায়।
এই permission package-কেন্দ্রিক: একই organization-এ থাকা মাত্রই consumer repository স্বয়ংক্রিয় access পায় না। Dependabot-এর প্রয়োজনীয় প্রতিটি private package-এর জন্য grant আলাদাভাবে নিশ্চিত করতে হবে। একই package একাধিক repository ব্যবহার করলে প্রয়োজনীয় প্রতিটি consumer repository-কেও access list-এ যোগ করতে হবে।
এই flow চালু করতে dependabot.yml পরিবর্তন আবশ্যক নয়। Dependabot-এর package টানার জন্য Read access-ই ঘোষিত শর্ত; Write বা administrative access দেওয়ার প্রয়োজন নেই। ফলে PAT সরানোর সুযোগ তৈরি হলেও কোন repository কোন package পড়তে পারবে, সেই সিদ্ধান্ত package administrator-এর হাতেই থাকে।
PAT সরানোর আগে migration-এর ক্রম
পুরোনো credential একবারে মুছে না দিয়ে permission, authentication ও routing আলাদা ধাপে যাচাই করা নিরাপদ। GitHub-এর ঘোষিত access model ও fallback precedence অনুসারে migration-টি এভাবে সাজানো যায়:
- dependabot.yml এবং repository বা organization-এর Dependabot secrets দেখে কোন PAT শুধু GitHub Packages বা ghcr.io থেকে package পড়ার জন্য ব্যবহৃত হচ্ছে তা শনাক্ত করুন। একই secret অন্য registry বা automation-এ ব্যবহৃত হলে সেটি এই migration-এর অংশ নয়।
- প্রতিটি প্রয়োজনীয় package-এর Manage Actions access-এ সঠিক consumer repository যোগ করে Read access দিন। এই পর্যায়ে পুরোনো registry entry সচল রাখলে grant ও credential—দুটি পরিবর্তন একসঙ্গে ঘটবে না।
- Dependabot update job চালিয়ে package resolution পরীক্ষা করুন। বিশেষ করে npm configuration-এ private scoped package GitHub Packages থেকে এবং public dependency প্রত্যাশিত public registry থেকে আসছে কি না job log ও lockfile-এ মিলিয়ে দেখুন।
- সফল resolution নিশ্চিত হওয়ার পরে শুধু ওই GitHub-hosted package-এর PAT-ভিত্তিক registry entry সরান। Token-টির আর কোনো reference না থাকলে Dependabot secret store থেকেও সেটি মুছে দিন।
- পরবর্তী scheduled বা security update job-এ একই routing বজায় আছে কি না দেখুন। Package permission, repository transfer বা package ownership বদলালে access grant আবার পর্যালোচনা করতে হবে।
এই ক্রমের উদ্দেশ্য হলো ব্যর্থতার কারণ আলাদা রাখা। Grant দেওয়ার আগেই PAT মুছে ফেললে authentication failure এবং ভুল repository routing একই সময়ে দেখা দিতে পারে; আর আগের rollback-এর কারণ ছিল শুধু credential প্রত্যাখ্যান নয়, public npm package ভুল registry দিয়ে resolve হওয়া।
সব private registry PAT-মুক্ত হচ্ছে না
Automatic access কেবল Dependabot সমর্থিত GitHub Packages ecosystem এবং GitHub Container Registry-তে প্রযোজ্য। Artifactory, Azure DevOps Artifacts, Cloudsmith, Nexus বা অন্য third-party private registry এই GITHUB_TOKEN flow-এর আওতায় আসে না। একটি repository-তে GitHub Packages ও তৃতীয় পক্ষের registry দুটো থাকলে প্রথমটির PAT সরানো সম্ভব হলেও অন্যটির credential প্রয়োজন থাকতে পারে।
GitHub-এর private registry নির্দেশনা third-party registry-র জন্য token বা username-password Dependabot secret store-এ রেখে dependabot.yml-এ reference করার পদ্ধতি নথিভুক্ত করেছে। নির্দিষ্ট provider-এর ক্ষেত্রে OIDC-ভিত্তিক authentication-ও সমর্থিত, তবে সেটিও আলাদা configuration; GitHub Packages-এর নতুন automatic grant তার বিকল্প নয়।
সুতরাং ৮ সেপ্টেম্বরের পুনরায় চালু হওয়া সুবিধার নিশ্চিত সীমা তিনটি: package-টি GitHub-hosted হতে হবে, ecosystem-টি Dependabot সমর্থিত হতে হবে এবং Manage Actions access-এ consumer repository-র Read grant থাকতে হবে। এই শর্ত পূরণ হলে সংশ্লিষ্ট PAT entry সরানো যায়; explicit routing ও অন্য registry-র credentials অপরিবর্তিত থাকে।
আরও পড়ুন:
আমাদের নিউজলেটার নিন
সর্বশেষ Web3, AI ও ক্রিপ্টো সংবাদ সরাসরি আপনার ইনবক্সে পান।