همگام‌سازی

ric پروژه را هم روی میزبان نگه می‌دارد (تا ادیتور، git و linter شما آن را ببینند) و هم داخل یک کانتینر داکر (تا Rails، gemها و ابزارهای ساخت بتوانند آن را اجرا کنند). ric sync ابزاری است برای جابجا کردن فایل‌ها بین این دو.

از میزبان به کانتینر (پیش‌فرض)

$ ric sync

 
 از کانتینر به میزبان

$  ric sync --reverse

ric sync باید از داخل پوشه‌ی پروژه‌ای که با ric new ساخته شده اجرا شود. نام پوشه همان نام کانتینر است.

• ric sync فایل‌های پوشه‌ی پروژه‌ی شما را داخلکانتینر کپی می‌کند. بعد از اینکه کد را روی میزبان ویرایش کردید (مثلا یک کنترلر را در VS Code ذخیره کردید) از این استفاده کنید تا کانتینر تغییرات را ببیند.

• ric sync --reverse فایل‌ها را ازکانتینربهمیزبان برمی‌گرداند. بعد از اجرای generator یا هر دستوری در کانتینر که فایل جدیدی تولید کرده (migration، مدل جدید، تست تولیدشده) از این استفاده کنید.

ric sync عمدا دو پوشه را نادیده می‌گیرد:

• tmp/ — کش‌ها، PIDها و سایر فایل‌های موقت که نباید بین این دو جابجا شوند.

• storage/ — فایل‌های Active Storage و دیتابیس‌های SQLite دولوپمنت شما. این‌ها به فایل‌سیستم کانتینر تعلق دارند و نباید توسط آنچه روی میزبان هست (یا نیست) بازنویسی شوند.

برای هر آیتم سطح بالای پوشه که tmp/ یا storage/ نیست، ric نسخه‌ی مقصد را پاک می‌کند و سپس docker cp -a می‌زند تا جایگزین کند. این یک sync درشت‌دانه است — سریع، ساده و قابل پیش‌بینی. برای diffهای سطح زیرفایل مناسب نیست، اما دقیقا همان چیزی است که برای «یکسان کردن این دو درخت فایل» می‌خواهید.

• بعد از نصب یک gem جدید (Gemfile را روی میزبان ویرایش کنید → ric sync → ric rails -- bundle install).

• بعد از اجرای یک generator داخل کانتینر (ric rails -- generate model … → ric sync --reverse).

• پیش از ric deploy اگر می‌خواهید مطمئن شوید کانتینر آخرین ویرایش‌های شما را دارد.

(بیشتر دستورهای ric که چیزی را داخل کانتینر اجرا می‌کنند — مثل ric rails — بعد از پایان کار، تغییرات را خودشان به میزبان برمی‌گردانند، پس معمولا فقط برای جهت میزبان→کانتینر به ric sync نیاز دارید.)