গ্র্যাডেল কনফিগারেশন ক্যাশের জাল

আমাদের প্লাগইন তৈরি করার অ্যাভেন্টুয়া`site-baker`, আমরা একটি কঠোর TDD পদ্ধতি অনুসরণ ছিলাম। প্রতিটি ফিচার পরীক্ষিত, যাচাইকৃত, এবং আমরা বিশ্বাসের সাথে অগ্রসর হইতাম। এবং একটি দিন, অপ্রত্যাশিত ঘটনা ঘটেছিল। বিল্ডগুলি অসংগতভাবে আচরণ করা শুরু করল। প্লাগইন লজিক বা কনফিগারেশন ফাইলে পরিবর্তনগুলি উপেক্ষা করা হচ্ছে মনে হত, এবং আমাদের ফাংশনাল টেস্টগুলো, আগে নির্ভরযোগ্য ছিল, কোনোকারণ না দেখায় ব্যর্থ হত।

এ ধরনের সমস্যা অবিশ্বাস্যরূপে চিড়নাকর হতে পারে। এটি টুলের নির্ভরযোগ্যতা এবং আমাদের কোডের বৈধতার প্রশ্ন উঠায়। একটি شدتপূর্ণ ডিবাগিং সেশনের पश्चাত, দুষ্টকে সনাক্ত করা হয়েছে :Gradle কনফিগারেশন ক্যাশ.

সমস্যা বহু উপায়ে প্রকাশিত হচ্ছিল :

সবকিছু হচ্ছে যেন Gradle আমাদের বিল্ডের একটি "ভূতীয় সংস্করণ" চালাচ্ছে, আমাদের সবচেয়ে নতুন পরিবর্তনগুলোকে উপেক্ষা করে।

কনফিগারেশন ক্যাশ হল Gradle-এ আপেক্ষিকভাবে আধুনিক এবং খুবই শক্তিশালী একটি বৈশিষ্ট্য, নতুন সংস্করণlarda ডিফল্টরূপে সক্রিয়। এর লক্ষ্য হল বিল্ডকে দ্রুত করা।

বড় প্রকল্পগুলিতে সময় সংরক্ষণ অসাধারণ। কিন্তু, এই কর্মক্ষমত에는 একটি খরচ আছে: এটি প্লাগইন কীভাবে লেখা উচিত সেই বিষয়ে কঠোর নিয়ম প্রয়োগ করে।

আমাদের প্লাগইন`site-baker`অজ্ঞাতভাবে কনফিগারেশন ক্যাশের অনেক নিয়ম লঙ্ঘিত করছিল। একটি কাজ গ্রাফ সিরিয়ালাইজযোগ্য হলে, কাজগুলোকে জটিল অবজেক্টের রেফারেন্স ধারণ করা উচিত নয়, যেমন এই বস্তু।`Project`অথবা ফাইলগুলোকে বিয়োগত পড়া যায় এক্সিকিউশন পর্যায়ে।

আমাদের মূল ভুল ছিল YAML ফাইলের কন্টেন্টকে সরাসরি কাজের লজিকের ভিতরে পড়া, আমাদের এক্সটেনশনে সংরক্ষিত পথের রেফারেন্স ব্যবহার করে। এই পদ্ধতিটি ক্যাশের সাথে অসংস্পত, কারণ Gradle বুঝতে পারে না ফাইলের কন্টেন্ট পরিবর্তিত হয়েছে কি না যদি এই পড়াকে একটি olarak মডেল করা না হয়।কার্য প্রবেশ(টাস্ক ইনপুট)

আমাদের ব্লক খুলে একটি পূর্বাভাসযোগ্য বিল্ড আচরণ ফিরে পেতে, সবচেয়ে দ্রুত সমাধানটি কনফিগারেশন ক্যাশ অক্ষম করা ছিল। ফাইলে নিম্নলিখিত লাইন যোগ করলে যথেষ্ট।gradle.properties`প্লাগইন ব্যবহার করে প্রজেক্টের (আমাদের_CASEে, টেস্ট প্রজেক্ট)`site-baker).

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

তবে, এটি একটি চুক্তি সমাধান, একটি স্থায়ী সমাধান নয়। এটি কর্মক্ষমতা ত্যাগ করে এবং আমাদের প্লাগইনের মৌলিক সমস্যা সমাধান করে না।

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

কী হল ব্যবহার করাপ্রোভাইডার এপিআইGradle-কে। বরং সরাসরি মান পাস না করে (যেমন একটি`String` ou un File) আমাদের কাজের জন্য, আমাদের কিছু সময় বিতরণ করতে হবে`Property<T>`বা কয়েক`Provider<T>`.

এখানে রিফ্যাক্টরিং পরিকল্পনা:

[source,kotlin] ---- @get:InputFile অবস্ট্রেক্ট বাল configFile: RegularFileProperty ----