‏رد کردن محیط موقتی PR با یه لیبل گیت‌هاب

متیو آلفورد از Octopus Deploy می‌گه فرایند بیلد و ریلیز چند سایت استاتیک داخلی‌شون رو مدرن کرده و حالا برای هر Pull Request یه محیط موقتی (ephemeral environment) بالا میاد و لینکش به‌صورت کامنت زیر PR گذاشته می‌شه — یه محیط واقعی و کارا که سازندهٔ PR و ریویوئرها بتونن تغییرات رو توش ببینن.

ولی به گفتهٔ نویسنده، چند بار ازش پرسیدن که می‌شه این مرحله رو رد کرد یا نه. دلیلش هم منطقیه: ساخت این محیط (یه Storage Account روی Azure با ترافرم و بعد دیپلوی پکیج سایت) بین ۵ تا ۹ دقیقه طول می‌کشه و چون بخشی از بیلد به حساب میاد، تکمیل چک‌های اجباری PR رو عقب می‌ندازه. تو ریپوهای شلوغ هم هزینهٔ زیرساختی که برای هر PR تأمین می‌شه، تو مقیاس بزرگ واقعاً پول می‌بره.

جمع‌بندی نویسنده اینه که تصمیم دربارهٔ محیط موقتی وابسته به بافته: به جنس تغییر و نیاز ریویوئر بستگی داره. پس به‌جای حذف کامل، باید بشه برای هر PR جداگونه اختیاری‌ش کرد — اون هم با کم‌ترین اصطکاک برای توسعه‌دهنده. و ابزار مناسبش از آب دراومد: لیبل‌های PR گیت‌هاب.

قدم اول شکستن ورک‌فلوی تک‌جابی به سه جاب بود: build که همیشه اجرا می‌شه (نصب وابستگی‌ها، بیلد، تست، پکیج و آپلود آرتیفکت)، deploy-ephemeral که آرتیفکت رو برمی‌داره و محیط موقتی رو می‌سازه — همونی که قراره اختیاری بشه — و pr-ready که یه جاب سبک دروازه‌بانه. کل ترفند اختیاری‌کردن، یه شرط if: روی جاب دیپلویه:

deploy-ephemeral:
  runs-on: ubuntu-latest
  needs: build
  if: ${{ !contains(github.event.pull_request.labels.*.name, 'skip-ephemeral') }}

ولی همین شکستن ورک‌فلو یه مشکل تازه ساخت. تو گیت‌هاب، جابی که skip می‌شه برای required check مثل جابِ failed حساب می‌شه؛ یعنی PR قفل می‌شد، دقیقاً وقتی که همه‌چی طبق نقشه پیش رفته بود.

راه‌حل همون جاب pr-ready ـه: با if: always() همیشه اجرا می‌شه و فقط دو چیز رو بررسی می‌کنه — این‌که build موفق بوده، و این‌که deploy-ephemeral یا موفق بوده یا عمداً skip شده. اگه این شرط‌ها برقرار نباشه با exit 1 می‌افته و merge رو می‌بنده. حالا required check برنچ main به‌جای دو جاب دیگه، به همین جاب نگاه می‌کنه.

استفاده‌ش برای توسعه‌دهنده سرراسته: موقع ساخت PR لیبل skip-ephemeral رو بزن، تمام. فقط یه نکتهٔ ریز داره — لیبل باید قبل از تریگر شدن ورک‌فلو روی PR باشه، چون وضعیت لیبل‌ها از payload همون رویداد خونده می‌شه. اگه وسط اجرا لیبل رو اضافه کنی، روی اون ران اثر نداره و باید یه کامیت جدید پوش کنی.

نویسنده آخرش زاویهٔ Platform Engineering ماجرا رو برجسته می‌کنه: چون ورک‌فلوی این سایت‌ها مشترک و نسخه‌بندی‌شده‌ست، همین یه تغییر بلافاصله در اختیار همهٔ تیم‌هایی قرار می‌گیره که ازش استفاده می‌کنن. اگه هر تیم کپی خودش رو از پایپلاین داشت، بهبود همون‌جا حبس می‌شد. البته تأکید می‌کنه که خودش این کار رو پیش‌فرض نمی‌کنه و ترجیحش اینه که محیط موقتی سر جاش بمونه.

نکات کلیدی:

• محیط موقتی برای هر PR ارزشمنده، ولی همیشه لازم نیست — ۵ تا ۹ دقیقه و هزینهٔ زیرساخت می‌بره.
• ورک‌فلو به سه جاب شکسته شده: build، deploy-ephemeral (اختیاری) و pr-ready (دروازه‌بان).
• یه شرط if: روی جاب دیپلوی، وجود لیبل skip-ephemeral رو چک می‌کنه.
• جابِ skip‌شده تو گیت‌هاب مثل چک ناموفق حساب می‌شه؛ جاب pr-ready با if: always() این تله رو خنثی می‌کنه.
• لیبل باید قبل از تریگر شدن ورک‌فلو زده بشه، وگرنه روی اون ران اثری نداره.