وقتی ساخت برنامه در GitHub Actions انجام می‌شود، ارسال دستی خروجی به سرویس رایانش لبه یک مرحلهٔ جداگانه به فرایند انتشار اضافه می‌کند. پروژهٔ ar-ec-action این مرحله را وارد همان گردش‌کار می‌کند: فایل JavaScript آماده را می‌گیرد و با ابزار خط فرمان ابرآروان به برنامهٔ مقصد در سرویس Edge Computing می‌فرستد.
این اکشن مسئول ساخت یا bundle کردن کد نیست. ابتدا باید خروجی سازگار با سرویس رایانش لبه را در مخزن داشته باشید یا آن را در مرحله‌ای قبلی بسازید؛ سپس نام برنامه، مسیر فایل و توکن دسترسی را به اکشن بدهید.
اکشن چگونه کار می‌کند؟
اکشن در یک کانتینر Docker اجرا می‌شود و منطق آن با Bash نوشته شده است. ابتدا ورودی‌های ضروری و وجود فایل را بررسی می‌کند، سپس فرمان arvan ec deploy را با نام برنامه و مسیر bundle اجرا می‌کند. اطلاعات بازگشتی ابزار خط فرمان هم به خروجی‌های قابل‌استفاده در مراحل بعدی تبدیل می‌شوند.
در Dockerfile نسخهٔ ۱٫۰٫۳، ابزار ArvanCloud CLI با نسخهٔ 0.4.0 دریافت و آرشیو آن با مقدار SHA-256 ثبت‌شده مقایسه می‌شود. ساخت ایمیج دو مرحله دارد؛ ابزار دانلود در مرحلهٔ اول می‌ماند و فایل اجرایی CLI به ایمیج نهایی مبتنی بر Debian منتقل می‌شود.
پیش‌نیازها
- یک برنامهٔ مقصد در سرویس رایانش لبهٔ ابرآروان و توکنی که به آن دسترسی داشته باشد.
- فایل JavaScript آمادهٔ استقرار، موجود در فضای کاری runner پیش از اجرای اکشن.
- یک runner لینوکسی با معماری
amd64یاarm64و امکان اجرای Docker؛ مانندubuntu-latestیا runner لینوکسی خودمیزبان. - دسترسی شبکه برای ساخت کانتینر، دریافت CLI و ارتباط با سرویس ابرآروان.
طبق راهنمای پروژه، کلید API را از بخش Profile → API Keys در پنل ابرآروان بسازید. سپس در تنظیمات مخزن گیت‌هاب، مسیر Settings → Secrets and variables → Actions، آن را با نام ARVAN_API_KEY ذخیره کنید. مقدار را دقیقاً همان‌طور که پنل نمایش می‌دهد، همراه با پیشوند احتمالی و بدون افزودن کوتیشن، کپی کنید.
نمونهٔ گردش‌کار
مثال زیر فرض می‌کند برنامهٔ شما یک پروژهٔ npm با فایل package-lock.json و اسکریپت build است و اجرای آن فایل dist/bundle.js را تولید می‌کند. این ساختار مربوط به برنامهٔ نمونه است؛ خود اکشن ابزار build مشخصی را تحمیل نمی‌کند.
فایل .github/workflows/deploy.yml را به این شکل تعریف کنید:
name: Deploy to ArvanCloud Edge Computing
on:
push:
branches: [main]
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v7
- uses: actions/setup-node@v7
with:
node-version: 24
cache: npm
- name: Build bundle
run: npm ci && npm run build
- name: Deploy bundle
id: deploy
uses: hatamiarash7/ar-ec-action@v1.0.3
with:
auth: ${{ secrets.ARVAN_API_KEY }}
app: my-edge-app
file: bundle.js
working-directory: dist
- name: Show deployment result
env:
DEPLOYMENT_ID: ${{ steps.deploy.outputs.id }}
DEPLOYMENT_STATUS: ${{ steps.deploy.outputs.status }}
run: printf 'Deployment %s is %s\n' "$DEPLOYMENT_ID" "$DEPLOYMENT_STATUS"نام my-edge-app یک مقدار نمونه است و باید با نام برنامهٔ مقصد جایگزین شود. مسیر خروجی و فرمان ساخت را هم با پروژهٔ خودتان هماهنگ کنید. اگر bundle از قبل در مخزن قرار دارد، مراحل نصب Node.js و ساخت لازم نیستند؛ مرحلهٔ checkout همچنان فایل را در اختیار اکشن می‌گذارد.
در این مثال، با هر push به شاخهٔ main فرایند ساخت و ارسال آغاز می‌شود. نسخهٔ اکشن به تگ مشخص محدود شده است؛ برای ثابت‌کردن دقیق کد مصرفی می‌توانید از SHA کامل یک commit استفاده کنید.
ورودی‌ها و مسیر فایل
ورودی‌های تعریف‌شده در فایل action.yml عبارت‌اند از:
| ورودی | وضعیت | کاربرد و مقدار پیش‌فرض |
|---|---|---|
auth |
الزامی | توکن API ابرآروان؛ از Secret خوانده شود |
app |
الزامی | نام برنامهٔ مقصد در سرویس Edge Computing |
file |
اختیاری | نام یا مسیر فایل bundle؛ پیش‌فرض main.js |
working-directory |
اختیاری | پوشهٔ مبنای مسیر فایل؛ پیش‌فرض ریشهٔ مخزن |
ترکیب working-directory: dist و file: bundle.js به فایل dist/bundle.js اشاره می‌کند. برای پروژه‌هایی که خروجی ساخت را در پوشه‌ای جدا نگه می‌دارند، همین دو ورودی کافی‌اند و نیازی به جابه‌جایی فایل نیست.
خروجی‌ها و وضعیت انتشار
اکشن سه خروجی در اختیار مراحل بعدی می‌گذارد:
id: شناسهٔ استقرار ایجادشده.status: وضعیت گزارش‌شده از سرویس، برای مثالpending.created-at: زمان ایجاد استقرار.
برای خواندن این مقادیر باید مرحلهٔ اکشن یک id داشته باشد؛ در مثال بالا deploy است. عبارت ${{ steps.deploy.outputs.id }} شناسهٔ استقرار را برمی‌گرداند. پس از اجرای موفق نیز جدولی شامل نام برنامه، مسیر bundle، شناسه و وضعیت در بخش Job summary ثبت می‌شود.
موفقیت مرحله به معنی پایان انتشار روی لبه نیست. سرویس، انتشار نسخهٔ جدید را به‌صورت غیرهم‌زمان ادامه می‌دهد و وضعیت اولیه می‌تواند pending باشد. اکشن تا رسیدن به وضعیت نهایی منتظر نمی‌ماند؛ برای بررسی نتیجهٔ نهایی از پنل یا فرمان arvan ec list در محیطی با CLI و دسترسی تنظیم‌شده استفاده کنید.
نکات استفاده و رفع خطا
- فایل پیدا نمی‌شود: ترتیب checkout، ساخت و استقرار را بررسی کنید. مسیر
fileنسبت بهworking-directoryمحاسبه می‌شود و وجود پوشه به‌تنهایی کافی نیست؛ خود فایل باید ساخته شده باشد. - استقرار بدون توضیح روشن شکست می‌خورد: راهنمای پروژه این وضعیت را از نشانه‌های احتمالی توکن نامعتبر، منقضی‌شده یا فاقد دسترسی به برنامه می‌داند. اکشن در این حالت هشدار راهنما می‌دهد؛ علت قطعی را با بررسی اعتبار توکن و دسترسی برنامه مشخص کنید.
- برنامه هنوز تغییر نکرده است: ابتدا وضعیت استقرار را بررسی کنید؛ پاسخ
pendingتأیید آماده‌بودن نسخهٔ جدید برای سرویس‌دهی نیست. - توکن را در YAML ننویسید: اکشن آن را به شکل متغیر محیطی به کانتینر منتقل می‌کند و برای پنهان‌شدن مقدار در لاگ از سازوکار mask گیت‌هاب استفاده می‌کند. توکن را همچنان در Secrets نگه دارید و در مراحل دیگر چاپ نکنید.
- runner باید لینوکسی باشد: این پروژه یک Docker action است و مستقیماً روی runnerهای Windows یا macOS اجرا نمی‌شود.
جزئیات اجرای فرمان، پردازش خروجی و گزارش خطا در اسکریپت ورودی قابل بررسی است. پروژه با مجوز MIT منتشر شده و برای اتصال مرحلهٔ ساخت برنامه به استقرار روی رایانش لبهٔ ابرآروان، یک مرحلهٔ قابل‌استفادهٔ مجدد در GitHub Actions فراهم می‌کند.