دایرکتوری Build در Cargo به مرز جدید کش برای CI کانسترهای Rust تبدیل می‌شود

Cargo به‌صورت تدریجی در حال تغییر مرز میان آرتیفکت‌های build در Rust است. یک به‌روزرسانی اخیر پروژه Rust می‌گوید تیم Cargo در مسیر ساخت کشی مشترک میان workspaceهاست و چیدمان بازطراحی‌شده build-dir پیش‌نیاز این کار محسوب می‌شود.

تحول فعلی یک فلگ جدید کامپایلر یا فرمان پایدار برای کش نیست. Cargo مسئولیت‌های قبلی target-dir را به artifact-dir و build-dir تقسیم کرده و فایل‌ها را بر اساس واحدهای build بازسازمان‌دهی کرده است. هدف پذیرفته‌شده پروژه Rust برای سال ۲۰۲۶ این است که از این ساختار برای استفاده مجدد از واحدهای کامپایل‌شده میان workspaceها، کاهش مصرف دیسک ناشی از فایل‌های تکراری و در آینده آسان‌تر کردن کش‌های راه‌دور یا مبتنی بر CI استفاده کند.

این موضوع برای توسعه‌دهندگان ICP مهم است، چون مخزن‌های کانستر معمولاً یک گراف وابستگی مشابه را میان اعضای workspace، مثال‌ها، تست‌های یکپارچه و jobهای مربوط به build و انتشار تکرار می‌کنند. کش مشترک می‌تواند کامپایل‌های تکراری را کاهش دهد؛ اما این امر مستلزم آن است که CI چیدمان آرتیفکت Cargo را یک مرز پیاده‌سازی بداند و مسیرهای امروزی target را به‌صورت ثابت در اسکریپت‌ها فرض نکند.

کار Cargo همچنین یادآوری می‌کند که درستی کش فقط به تولید آرتیفکت محدود نیست و پاک‌سازی را هم شامل می‌شود. در جریان پایدارسازی این چیدمان، اصلاح جداگانه‌ای برای حذف فایل‌های unremap هنگام اجرای cargo clean -p با چیدمان جدید انجام شد. این فایل‌ها همراه آرتیفکت‌های نهایی هستند؛ بنابراین باقی ماندنشان باعث می‌شود پاک‌سازی انتخابی، حتی در صورت موفقیت کامپایل، ناقص باشد.

چند بررسی عملی برای workspaceهای Rust در ICP:

• از اسکریپت‌هایی که فرض می‌کنند همه آرتیفکت‌های کامپایل زیر مسیر ثابتی مانند target/<profile> هستند، دوری کنید.
• فرمان cargo clean -p <package> را با نسخه‌های toolchain مورد استفاده در CI آزمایش کنید.
• خروجی‌های build را از بسته‌بندی Wasm قابل انتشار و خروجی‌های تولید Candid یا رابط‌ها جدا نگه دارید.
• آزمایش‌های کش روی nightly را تغییرات اختیاری زیرساخت در نظر بگیرید و برای آن‌ها تست ابطال کش و بازتولیدپذیری داشته باشید.

ملاحظه غیرمسدودکننده مهم است: کش میان workspaceها یک هدف پذیرفته‌شده پروژه Rust برای سال ۲۰۲۶ است، نه یک قابلیت پایدار Cargo. این هدف، پیاده‌سازی اولیه روی nightly، گسترش تدریجی و ارزیابی پیش از پایدارسازی را توضیح می‌دهد و همچنین می‌گوید پایدارسازی ممکن است در دوره این هدف کامل نشود. بنابراین سازندگان باید ابزارهای مقاوم در برابر تغییر مسیرها آماده کنند، اما امروز به کش آینده وابسته نشوند.

زاویه جدید، عملیاتی است: دایرکتوری build در Cargo در حال تبدیل شدن به مرزی برای قابلیت حمل و کش است. برای تیم‌های ICP، آماده‌سازی امن‌تر این است که CI آرتیفکت‌ها را بر اساس فراداده و فرمان‌های مدیریت‌شده توسط Cargo بشناسد، نه بر اساس این فرض که درخت دایرکتوری فعلی برای همیشه ثابت می‌ماند.