فایل‌های پیکربندی

بیشتر تنظیمات سرویس در پنل است، ولی چند فایل داخل پروژه هم روی ساخت و اجرا اثر دارند:

فایل	اثر	توضیح
`Dockerfile`	اگر باشد، همان ساخته می‌شود	ساخت با Dockerfile
`.nvmrc`، `.python-version`، `go.mod`، …	نسخهٔ زبان	نسخهٔ زبان
`vercel.json`	redirect، rewrite و هدرهای سایت‌های استاتیک	پایین همین صفحه
`gerdoo.json`	پیش‌فرض‌های `gerdoo deploy`	پایین همین صفحه
`.gerdooignore`	فایل‌هایی که CLI نمی‌فرستد	بارگذاری پوشه

vercel.json

اگر سایتتان را از Vercel آورده‌اید، vercel.json را نگه دارید. گردو آن را برای این استک‌ها اعمال می‌کند: سایت استاتیک، React، Vue، SvelteKit (استاتیک) و Astro. برای Next.js و برنامه‌هایی که سرور خودشان را دارند، vercel.json خوانده نمی‌شود.

این کلیدها پشتیبانی می‌شوند:


{
  "cleanUrls": true,
  "trailingSlash": false,
  "outputDirectory": "build",
  "buildCommand": "npm run build:prod",
  "redirects": [
    { "source": "/blog/:slug", "destination": "/posts/:slug", "permanent": true }
  ],
  "rewrites": [
    { "source": "/app/:path*", "destination": "/app/index.html" }
  ],
  "headers": [
    { "source": "/assets/**", "headers": [{ "key": "Cache-Control", "value": "public, max-age=31536000, immutable" }] }
  ]
}

outputDirectory و buildCommand فقط جای پیش‌فرض استک را می‌گیرند. اگر در تنظیمات سرویس دستور ساخت را نوشته باشید، تنظیمات سرویس برنده است.
اگر «دستور اجرا» را در تنظیمات سرویس پر کرده باشید، redirectها و هدرهای vercel.json اعمال نمی‌شوند.
routes قدیمی (پیش از ۲۰۲۰) هم خوانده می‌شود، تا جایی که قابل تبدیل باشد.
فایلی که واقعاً روی دیسک هست بر rewrite اولویت دارد، مثل خود Vercel.

قانون‌هایی که اعمال نمی‌شوند

قانونی که نشود دقیقاً همان‌طور اجرایش کرد کنار گذاشته می‌شود و گزارش ساخت دلیلش را می‌نویسد، مثلاً:


Applying vercel.json: cleanUrls=true, 3 redirects, 1 rewrite
vercel.json: skipped rewrite #2 (/api/:path*): rewrites to another origin (proxying) are not supported

این‌ها پشتیبانی نمی‌شوند:

rewrite به دامنهٔ دیگر (proxy کردن، مثلاً /api/:path* به یک API بیرونی). به جایش آدرس API را مستقیم در فرانت‌اند صدا بزنید.
شرط‌های has و missing.
بیشتر از یک catch-all (:path*) در هر source، یا catch-all که آخرین بخش آدرس نباشد.
استفادهٔ catch-all در destination برای rewrite (مقدارش / دارد و درست جایگذاری نمی‌شود). redirect با catch-all مشکلی ندارد.
الگوهای سفارشی پارامتر مثل :id(\\d+).

در headers، source الگوی فایل (glob) است: /assets/** یعنی هر چیزی زیر assets.

اگر vercel.json اصلاً JSON معتبر نباشد، کامل نادیده گرفته می‌شود و گزارش ساخت می‌گوید: vercel.json: ignored, not valid JSON.

gerdoo.json

gerdoo.json در ریشهٔ پروژه پیش‌فرض‌هایی می‌دهد که gerdoo deploy، gerdoo check و ابزارهای عامل هوشمند هنگام ساخت سرویس تازه استفاده می‌کنند. با آن، هر کس پروژه را clone کند با همان تنظیمات منتشرش می‌کند.


{
  "name": "shop-api",
  "project": "shop",
  "framework": "node",
  "port": 8080,
  "private": false,
  "build_command": "npm run build",
  "start_command": "node dist/server.js",
  "root_dir": "apps/api",
  "env": { "LOG_LEVEL": "info" },
  "env_required": ["DATABASE_URL", "JWT_SECRET"],
  "health_path": "/healthz"
}

کلید	یعنی
`name`، `project`	نام سرویس و اپلیکیشنی که در آن ساخته می‌شود
`framework`	استک، اگر نمی‌خواهید خودکار تشخیص داده شود
`port`، `private`	پورت داخلی، و اینکه سرویس آدرس عمومی نداشته باشد
`build_command`، `start_command`	دستورهای ساخت و اجرا
`root_dir`، `dockerfile`، `build_context`	مثل همین تنظیمات در پنل
`env`	متغیرهای غیرمحرمانه
`env_required`	نام متغیرهایی که باید قبل از استقرار تعریف شده باشند؛ `gerdoo check` اگر نباشند هشدار می‌دهد
`health_path`	مسیری که بعد از استقرار برای اطمینان از سالم بودن سرویس صدا زده می‌شود

gerdoo.json معمولاً در گیت commit می‌شود. هیچ رمزی در env آن نگذارید؛ رمزها را با gerdoo service vars set … --secret تعریف کنید و فقط نامشان را در env_required بنویسید.

پرچم‌های خط فرمان (--port، --name، …) بر gerdoo.json اولویت دارند.
gerdoo.json فقط موقع ساخت سرویس خوانده می‌شود و سرویس موجود را دوباره تنظیم نمی‌کند. برای تغییر سرویس موجود از پنل یا gerdoo service update استفاده کنید.
گردو فایل gerdoo.toml را نمی‌خواند؛ قالب فقط JSON است.

در سایت گردومیزبانی سایت استاتیک در گردو