‏CI باید یک‌بارمصرف باشه

نویسنده تو یه پست کوتاه یه قانون ساده پیشنهاد می‌کنه: سرویس CI (یعنی همون سیستمی که بعد از هر push خودکار پروژه رو می‌سازه و تست می‌کنه) فقط باید تصمیم بگیره کارها کِی اجرا بشن. خود ساختن پروژه باید دست خودت باشه، با ابزاری مثل Docker، Nix یا حتی یه Makefile ساده.

به گفتهٔ نویسنده فایل workflow ایده‌آل تقریباً همین‌قدر خلوته:

steps:
    name: Do the thing
     run: nix build .#

وقتی کل بیلد پشت یه دستور جمع شده، همون دستور رو روی لپ‌تاپ خودت هم می‌زنی و دقیقاً همون خروجی رو می‌گیری. یعنی دیگه لازم نیست برای دیباگ یه خطای بیلد، پشت سر هم کامیت آزمایشی بزنی تا ببینی سرور چی می‌گه.

نکتهٔ دوم اینه که CI جای نصب پکیج، کامپایلر، کتابخونهٔ اشتراکی و toolchain نیست. تا وقتی این چیزا تو کانفیگ همون سرویس تعریف شدن، محیط بیلدت به یه سرویس بیرونی گره خورده و عملاً جای دیگه قابل بازتولید نیست.

حرف آخر نویسنده همینه: دفعهٔ بعد که GitHub Actions از دسترس خارج شد، تیمی که بیلدش یک‌بارمصرف و مستقل از سرویسه، همچنان می‌تونه نسخه بده. آخر پست یه سرویس جایگزین رو هم پیشنهاد می‌کنه.

نکات کلیدی:

• وظیفهٔ CI فقط زمان‌بندیه؛ منطق بیلد باید تو Docker، Nix یا Makefile خود پروژه باشه
• فایل workflow ایده‌آل یه step با یه دستور مثل nix build .# داره
• نصب پکیج، کامپایلر، کتابخونهٔ اشتراکی و toolchain نباید تو CI انجام بشه
• وقتی بیلد یه دستوره، همون رو لوکال هم اجرا می‌کنی و به قطعی GitHub Actions وابسته نیستی