CI حافظه‌دار

`zev-ci` می‌تواند اجرای دوبارهٔ یک گام خط‌لوله را کاملاً کنار بگذارد، وقتی آن گام پیش‌تر با دقیقاً همان ورودی‌ها با موفقیت اجرا شده باشد. ## «همان ورودی‌ها» یعنی چه کلید حافظه از سه چیز ساخته می‌شود: هشی قطعی از کل درخت منبعی که گام روی آن اجرا می‌شود (مسیر و محتوای هر فایل، مرتب‌شده برای قطعیت، تا دو پوشه با فایل‌های یکسان صرف‌نظر از ترتیب پیمایش سامانهٔ فایل همیشه یک هش بدهند)، ایمیج کانتینر گام، و دستور دقیق گام. اگر هر سه با یک اجرای موفق پیشین یکی باشند، گام اجرا نمی‌شود. ## چرا فقط اجراهای موفق در حافظه می‌مانند اجرای ناموفق یا اجرایی که زمانش تمام شده هرگز ذخیره نمی‌شود. همان محتوا ممکن است واقعاً در اجرای دوباره نتیجهٔ دیگری بدهد (آزمون‌های ناپایدار، مشکلات گذرای محیط) و ذخیرهٔ دائمی یک شکست، یک مشکل واقعی و جاری را از همهٔ اجراهای بعدی پنهان می‌کرد به‌جای آنکه آشکارش کند. ## یک نتیجهٔ واقعی و اندازه‌گیری‌شده اجرای یک گام خط‌لوله دو بار روی منبع یکسان: اجرای اول واقعاً در Docker انجام می‌شود و ۰٫۵۳ ثانیه طول می‌کشد. اجرای دوم کاملاً از حافظه ارائه می‌شود (Docker اصلاً فراخوانده نمی‌شود) و ۰٫۰۱ ثانیه طول می‌کشد. تغییر منبع و اجرای سوم به‌درستی دوباره اجرای واقعی را راه می‌اندازد و محتوای تازه را بازتاب می‌دهد. ``` === RUN 1 (genuinely executes) === exit_code=0 === RUN 2, identical source (memoized) === (memoized: identical source+image+command previously succeeded, skipping execution) exit_code=0 === RUN 3, changed source (genuinely re-executes) === exit_code=0 ``` ## حافظه کجا نگه داشته می‌شود نتیجه‌های ذخیره‌شده به‌صورت فایل‌های دودویی ساده روی میزبان CI و با کلید هش محاسبه‌شده نگه داشته می‌شوند؛ قالبی با پیشوند طول برای کد خروج، پرچم پایان زمان، stdout و stderr، تا برای خروجی دودویی دلخواه هیچ پیچیدگی گریزدادن متن پیش نیاید. این سازوکار مستقیماً در مسیر واقعی اجرای خط‌لوله قرار دارد که هم سرویس تولیدی `zev-ci` و هم دستور `zev-ci-local` از آن استفاده می‌کنند؛ دستوری که همان تعریف خط‌لوله را پیش از ارسال، روی دستگاه خودتان اجرا می‌کند.