Copilot-এর approval-এ PR merge হতে পারে—মানুষের review কোথায় রাখবেন
GitHub ১ সেপ্টেম্বর ২০২৬-এ Copilot code review-এর pull request approval public preview চালু করেছে। প্রশাসক অনুমতি দিলে Copilot আনুষ্ঠানিক approving review জমা দিতে পারে; GitHub-এর ঘোষণায় সুবিধাটি default অবস্থায় বন্ধ এবং Copilot Pro, Pro+, Max, Business ও Enterprise পরিকল্পনায় preview হিসেবে উপলভ্য বলে জানানো হয়েছে।
এই approval repository-র required-approval rule পূরণ করতে পারে। ফলে protected branch-এ approval-ই যদি শেষ অসম্পূর্ণ merge condition হয়, Copilot-এর অনুমোদনের পর PR merge করা সম্ভব হতে পারে; তবে status check, conversation resolution, code-owner review বা ruleset-এর অন্য শর্ত থাকলে সেগুলোও আলাদাভাবে পূরণ করতে হবে।
Assessment নয়, আনুষ্ঠানিক approval-ই merge rule-এ গণ্য হয়
প্রতিটি Copilot code review-এর overview comment-এ এখন একটি approval assessment দেখা যায়। এটি পরিবর্তনগুলো অনুমোদনের উপযুক্ত বলে Copilot মনে করছে কি না জানায়, কিন্তু নিজে কোনো merge requirement পূরণ করে না।
প্রশাসক approval ক্ষমতা চালু করলে Copilot আলাদা করে একটি “Approve” review দিতে পারে। Required approval-এর সংখ্যা এক হলে এবং অন্য সব শর্ত আগে থেকেই পূরণ থাকলে, সেই review-ই approval count সম্পূর্ণ করতে পারে। Copilot নিজে PR merge করে না; তার review বিদ্যমান merge gate-এর একটি শর্ত পূরণ করে।
Repository policy-তে তাই assessment ও approval-কে একই জিনিস হিসেবে লেখা উচিত নয়। প্রথমটি Copilot-এর মূল্যায়ন; দ্বিতীয়টি এমন একটি অনুমোদন, যা প্রশাসকের configuration অনুযায়ী protected branch-এর সিদ্ধান্তে প্রভাব ফেলতে পারে।
তিন স্তরের control ও দুটি repository switch
Approval ক্ষমতা enterprise, organization ও repository স্তরে নিয়ন্ত্রিত হয়। Enterprise administrator এটি বন্ধ রাখতে বা organization-কে সিদ্ধান্ত নিতে দিতে পারেন। Organization owner সব repository-তে চালু করা, নির্বাচিত repository-তে সীমিত রাখা, repository administrator-কে সিদ্ধান্ত দেওয়া অথবা সর্বত্র বন্ধ রাখার বিকল্প পান।
Repository settings-এ দুটি পৃথক switch আছে: একটি Copilot-কে approving review জমা দিতে দেয়, অন্যটি সেই approval-কে merge requirement-এ গণনা করতে দেয়। ফলে প্রথম switch চালু রেখে দ্বিতীয়টি বন্ধ রাখা সম্ভব—Copilot-এর সিদ্ধান্ত reviewers তালিকায় দেখা যাবে, কিন্তু required-approval threshold বদলাবে না।
Public preview-তে এটিই কম-ঝুঁকির পর্যবেক্ষণপর্ব হতে পারে। দল Copilot কোন পরিবর্তন অনুমোদন করছে, মানুষের reviewer কোথায় দ্বিমত করছেন এবং কোন repository-তে approval counting আদৌ প্রয়োজন—এসব দেখে পরে দ্বিতীয় switch নিয়ে সিদ্ধান্ত নিতে পারে। এটি GitHub-এর বাধ্যতামূলক rollout নয়, বরং preview-stage control-এর জন্য সম্পাদকীয়ভাবে প্রস্তাবিত সীমিত প্রয়োগ।
Path allowlist দিয়ে AI approval-এর সীমানা টানুন
GitHub-এর configuration নির্দেশনা অনুযায়ী, repository administrator প্রতি লাইনে একটি করে সর্বোচ্চ ১৫টি file glob দিতে পারেন। PR-এর পরিবর্তিত প্রতিটি file অন্তত একটি অনুমোদিত glob-এর সঙ্গে মিললেই Copilot approval merge requirement-এ গণ্য হবে; field ফাঁকা থাকলে সব file-এর ক্ষেত্রেই তা গণ্য হতে পারে।
এই field-কে low-risk path-এর allowlist হিসেবে ব্যবহার করা নিরাপদ। Documentation, অনুবাদ, নির্দিষ্ট test fixture বা যাচাইযোগ্য generated artifact রাখা যেতে পারে—তবে এগুলো GitHub নির্ধারিত শ্রেণি নয়। কোন path কম ঝুঁকির, তা repository-র deployment প্রভাব, data access, secret exposure ও ownership দেখে দলকেই নির্ধারণ করতে হবে।
Mixed-path PR-এ নিয়মটি বিশেষ গুরুত্বপূর্ণ। একটি PR অনুমোদিত documentation file-এর পাশাপাশি allowlist-এর বাইরে application বা infrastructure file বদলালে “every changed file” শর্ত পূরণ হবে না; তাই Copilot approval count হওয়ার কথা নয়। ব্যবহৃত glob অতিরিক্ত বিস্তৃত হলে sensitive file-ও অনিচ্ছাকৃতভাবে মিলে যেতে পারে, তাই production repository-তে প্রয়োগের আগে একই pattern দিয়ে representative path পরীক্ষা করা যুক্তিসঙ্গত।
Sensitive code-এ তিন স্তরে মানুষের gate রাখুন
Authentication, authorization, payment, production infrastructure, deployment workflow, secret handling, database migration ও security policy-র path Copilot allowlist-এর বাইরে রাখা উচিত। এতে Copilot review বা মন্তব্য বন্ধ হয় না; শুধু তার approval ওই পরিবর্তনের required-approval count পূরণ করতে পারে না।
দ্বিতীয় স্তরে sensitive path-এর মালিক নির্ধারণে CODEOWNERS এবং branch rule-এ required code-owner review রাখুন। GitHub-এর প্রকাশিত approval documentation সাধারণ required-approval rule পূরণের কথা বললেও Copilot কোনো CODEOWNERS-required review পূরণ করতে পারে কি না স্পষ্ট করে না; একটি স্বাধীন কারিগরি বিশ্লেষণও এই অনথিভুক্ত সীমাটি চিহ্নিত করেছে। তাই মানব gate বজায় রাখার নীতি Copilot-এর অঘোষিত আচরণের ওপর নির্ভর করা উচিত নয়।
তৃতীয় স্তরে প্রয়োজনীয় generic approval count বজায় রাখা যায়। তবে শুধু সংখ্যা দুই করলেই দুইজন মানুষ review করেছেন—এ নিশ্চয়তা পাওয়া যায় না: Copilot-এর approval গণ্য হলে আর একজন মানুষের approval-ই threshold পূরণ করতে পারে। Human-only ফল নিশ্চিত করতে sensitive path-কে Copilot counting-এর বাইরে রাখাই মূল সীমানা; CODEOWNERS ও required approvals তার পরের প্রতিরক্ষা স্তর।
নতুন commit পুরোনো Copilot approval বাতিল করে
Copilot approval দেওয়ার পরে PR-এ নতুন commit push হলে আগের approval বাতিল হয়। নতুন অবস্থার জন্য আবার Copilot review চাইতে হয়। ফলে কম-ঝুঁকির diff অনুমোদন করিয়ে পরে গুরুত্বপূর্ণ code যোগ করে পুরোনো AI approval ধরে রাখার সরাসরি পথটি এই আচরণে বন্ধ থাকে।
Automatic review ruleset-এ “Review new pushes” চালু থাকলে পরবর্তী push-এর পর Copilot আবার review করতে পারে। সেটি চালু না থাকলে Copilot স্বয়ংক্রিয়ভাবে নতুন পরিবর্তন review করে না; re-review আলাদাভাবে চাইতে হয়। Approval বাতিল হওয়া এবং নতুন review স্বয়ংক্রিয়ভাবে শুরু হওয়া তাই দুটি পৃথক আচরণ।
বর্তমানে Copilot approval public preview এবং পরিবর্তনসাপেক্ষ। নিশ্চিত তথ্য হলো—এটি default-off, opt-in করলে সাধারণ required-approval rule পূরণ করতে পারে, file path দিয়ে counting সীমিত করা যায় এবং নতুন commit এলে approval বাতিল হয়। CODEOWNERS-এর সঙ্গে এর নির্দিষ্ট সম্পর্ক নথিভুক্ত না হওয়া পর্যন্ত low-risk allowlist, sensitive path exclusion এবং আলাদা human code-owner review-ই সবচেয়ে সংযত rollout policy।
আরও পড়ুন:
আমাদের নিউজলেটার নিন
সর্বশেষ Web3, AI ও ক্রিপ্টো সংবাদ সরাসরি আপনার ইনবক্সে পান।