GitHub Actions থেকে Node 20 সরেছে—পুরোনো action আর opt-out পাবে না

২৩ সেপ্টেম্বর ২০২৬-এ GitHub-এর চূড়ান্ত বিজ্ঞপ্তি অনুযায়ী, GitHub Actions runner থেকে Node 20 সরেছে; JavaScript action এখন Node 24-এ চলে এবং ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION opt-out আর পাওয়া যায় না। ফলে পুরোনো action-এর কোড নতুন runtime-এ না চললে workflow ব্যর্থ হতে পারে। পুরোনো runtime-এ ফেরার ওই সাময়িক পথটিও বন্ধ।

পরিবর্তনটি action চালানোর runtime নিয়ে; প্রকল্পের সব JavaScript পরীক্ষা বা run: ধাপের Node সংস্করণ একসঙ্গে বদলে যাওয়ার ঘোষণা নয়। কোনো action-এর metadata-তে runs.using: node20 থাকলে সেটি তদন্তের সংকেত; শুধু ওই লেখা দেখে প্রতিটি workflow ইতিমধ্যে ভেঙেছে বলা যায় না। নির্দিষ্ট release-এর কোড Node 24-এ চলে কি না এবং runner সেটি চালাতে পারে কি না, কার্যকর ফল তার ওপর নির্ভর করবে।

পুরোনো action আর প্রকল্পের Node একই জিনিস নয়

Workflow-র uses: ধাপে ডাকা JavaScript action এবং run: ধাপে চালানো প্রকল্পের কমান্ডের Node নির্বাচন আলাদা। actions/setup-node দিয়ে job-এর পরীক্ষার জন্য একটি Node সংস্করণ বসালেও অন্য repository থেকে ডাকা action-এর runtime তাতে বদলায় না। তাই package.json-এ সংস্করণ পাল্টানো বা run: ধাপে node --version দেখে সব ব্যবহৃত action প্রস্তুত ধরে নেওয়া ভুল। প্রকল্পের পরীক্ষা Node 20-এ চালানোর প্রয়োজন থাকলে সেটি action migration থেকে পৃথক সিদ্ধান্ত।

নিজের JavaScript action-এর action.yml বা action.yaml ফাইলে runs.using মান থাকে; ওই action-এর রক্ষণাবেক্ষণকারীকেই node24 দিয়ে নতুন release প্রকাশ করতে হবে। Workflow-র মালিকের কাজ হলো uses: reference-এ এমন release বেছে নেওয়া, যার metadata ও বিতরণ করা কোড নতুন runtime সমর্থন করে। প্ল্যাটফর্মের নিজস্ব action-গুলোর সর্বশেষ সংস্করণে পরিবর্তন এসেছে, কিন্তু পুরোনো tag বা স্থির commit SHA নিজে থেকে নতুন release-এ যায় না।

Repository-জুড়ে নির্ভরতা শনাক্ত করার তালিকা

প্রথমে .github/workflows-এর সব uses: reference খুঁজুন, শুধু নিজের action.yml-এ node20 খুঁজে থামবেন না। পুনরাবৃত্তিযোগ্য প্রাথমিক অনুসন্ধান হিসেবে rg -n --glob '*.yml' --glob '*.yaml' 'uses:' .github/workflows চালানো যায়। Nandann-এর migration বিশ্লেষণ একইভাবে সরাসরি ডাকা action, স্থানীয় action এবং reusable workflow-র reference আলাদা করে নথিবদ্ধ করার পরামর্শ দেয়।

প্রতিটি reference-এর পাশে repository, ব্যবহৃত tag বা commit SHA, সংশ্লিষ্ট job ও runner label লিখুন। job স্তরে অন্য repository-র reusable workflow ডাকলে তার ভেতরের uses: ধাপগুলোও অনুসরণ করতে হবে; মূল repository-র YAML-এ সেই পরোক্ষ JavaScript action দেখা যায় না। Workflow কোনো template থেকে তৈরি হলে template-টির reference-ও দেখুন, নইলে পরের তৈরি ফাইলে পুরোনো pin ফিরে আসতে পারে।

নিজেদের action-এর metadata-তে runs.using দেখুন। তৃতীয় পক্ষের action হলে workflow-তে যে tag বা SHA আটকানো আছে, ঠিক সেই revision-এর action.yml বা action.yaml খুলুন; default branch-এর বর্তমান ফাইল দেখে পুরোনো pin-এর অবস্থা বোঝা যাবে না। Composite action-এর ভেতরে ডাকা JavaScript action অনুসরণ করুন, তবে container action-এর runs.using: docker-কে node24-এ বদলানোর প্রয়োজন নেই।

তালিকার শেষ ঘরে রাখুন পরীক্ষার ফল: নির্বাচিত Node 24-সামঞ্জস্যপূর্ণ release, কোন trigger-এ কাজটি চলে এবং কোন runner pool সেটি চালায়। Release বা deployment job-এ নির্ভরতা থাকলে সেগুলো আগে যাচাই করা যুক্তিসঙ্গত। push-এ একটি সফল run, pull_request বা release-সংশ্লিষ্ট শর্তযুক্ত ধাপও সফল হবে—এমন নিশ্চয়তা দেয় না।

নিজের action-এর metadata ও বিতরণ করা কোড

নিজস্ব JavaScript action-এ runs.using: node24 বসানো দরকার, তবে শুধু metadata পাল্টালে কাজ শেষ হয় না। runs.main যে ফাইল চালায়, এবং থাকলে runs.pre ও runs.post যে ফাইল চালায়, সেগুলো নতুন runtime-এ পরীক্ষা করুন। Source code পরীক্ষায় পাস করলেও action যদি dist-এর তৈরি bundle চালায়, bundle পুনরায় তৈরি না করলে workflow ব্যবহারকারী পুরোনো প্রকাশিত কোডই চালাবেন।

স্থানীয় Node 24 পরিবেশে dependency install, test ও build চালিয়ে যে artefact release-এ যাবে সেটি যাচাই করুন। তারপর action যে বাস্তব trigger-এ চলে, বিশেষ করে cleanup বা ব্যর্থ job-এর পথ থাকলে, সেই পথও চালিয়ে দেখুন। নতুন release-এর metadata, bundle ও workflow-তে বসানো tag বা SHA একই revision-এর কি না মিলিয়ে নিন। তৃতীয় পক্ষের action-এর উপযুক্ত release না থাকলে রক্ষণাবেক্ষণকারীর প্রকাশিত সংস্করণ বা সমর্থিত বিকল্প খুঁজতে হবে; সরানো opt-out যোগ করে আর Node 20 ফেরানো যাবে না।

Self-hosted runner-এ host-এর সীমা

নিজস্ব runner-এর ক্ষেত্রে action-এর বাইরে host-এর operating system ও architecture-ও ফল নির্ধারণ করে। GitHub-এর আগের অবসরসূচি অনুযায়ী, ১৬ জুন ২০২৬ থেকে Node 24 ডিফল্ট হয় এবং Node 20-এ ফেরার সাময়িক opt-out শুধু ২৩ সেপ্টেম্বর ২০২৬-এ অপসারণ পর্যন্ত কার্যকর ছিল। Node 24 macOS 13.4 বা তার আগের সংস্করণের সঙ্গে অসামঞ্জস্যপূর্ণ; ARM32-তেও এর আনুষ্ঠানিক সমর্থন নেই।

তাই runs-on label-এর পাশাপাশি সেটি কোন যন্ত্রকে নির্দেশ করে, তার operating system-এর নির্দিষ্ট সংস্করণ, architecture এবং runner application-এর সংস্করণ নথিবদ্ধ করুন। একই label-এ ভিন্ন host থাকলে একটি সফল run পুরো pool-এর সামঞ্জস্য প্রমাণ করে না। macOS 13.4 বা পুরোনো host এবং ARM32 host-এর সমস্যার সমাধান শুধু নতুন action release নয়; সমর্থিত host বা architecture দরকার।

পরিবর্তনের সীমানা

ঘোষিত পরিবর্তন github.com এবং GitHub with Data Residency-তে প্রযোজ্য। GitHub Enterprise Server-এর জন্য একই সময়সূচি এই বিজ্ঞপ্তিতে নির্দিষ্ট করা হয়নি; তার অবস্থা সংশ্লিষ্ট সংস্করণের তথ্য দিয়ে বিচার করতে হবে। আর কোনো repository-র সব workflow ভাঙবে কি না, তার একক উত্তর নেই: ফল নির্ভর করছে সেটি কোন action release pin করেছে, তার প্রকাশিত কোড নতুন runtime-এ কেমন চলে এবং self-hosted runner সমর্থিত কি না তার ওপর।

আরও পড়ুন:

• GitHub Actions-এ নতুন ডিফল্ট বাধা—২ নভেম্বর ভাঙতে পারে কিছু workflow
• GitHub live migration এখন GA—repository চলবে, কিন্তু org settings যাবে না
• GitHub Actions cache-mode বসান—একটি ভুলে cache poisoning ফিরতে পারে