ضَع رقم الإصدار في عملية البناء الخاصة بك

يجب على مستخدمي برنامجك معرفة الإصدار الذي يستخدمونه. تقوم Coroid بتحديد رقم إصدار ورقم بناء لكل إصدار، ثم تمررهما إلى خط أنابيب البناء، وتتحقق بعد ذلك من أن البيئة تعمل بالفعل بالإصدار الذي تم نشره.

تم ضبط كل ما يوجد في هذه الصفحة حسب المشروع في الإصدارات ← إعدادات الإصدار → تحديد رقم الإصدار.

مصدر رقم الإصدار#

اختر مصدرًا واحدًا لكل مشروع:

• تقوم Coroid بتعيينه. (الافتراضي): تقترح Coroid الرقم التالي للإصدار عند تحضير إصدار جديد. حيث تزيد الرقم الأخير لأعلى إصدار تم نشره للمشروع، لذا 1.4.0 يتبعه 1.4.1. أما الإصدار الأول فهو 0.1.0. يمكنك كتابة رقم إصدار مختلف كلما احتجت إلى ذلك.
• قراءة الرقم من المستودع: تقرأ Coroid رقم الإصدار الذي يحدده الكود في التزام النشر. حيث تبحث في VERSION، package.json، app.json (Expo), pubspec.yaml، ملف Gradle الخاص بـ Android، Cargo.toml، pyproject.toml ومشروع Xcode، أو حتى في الملف الذي تحدده أنت. وإذا كان الملف لا يزال يحتوي على رقم إصدار استخدمه إصدار سابق، فإن Coroid تطلب منك زيادته أولاً.
• خط أنابيبي هو من يعينه: يقوم CI/CD الخاص بك بتحديد رقم الإصدار، مثلاً عبر أداة semantic-release أو من علامة، ثم يبلغ عنه أثناء عملية النشر.

يحصل كل إصدار أيضًا على رقم بناء. ولا يتكرر رقم البناء أبدًا داخل المشروع، وهو ما تطلبه متاجر التطبيقات من نظام iOS CFBundleVersion وAndroid versionCode.

ما يتم تمريره إلى عملية البناء#

عندما تبدأ Coroid سير عمل GitHub Actions أو خط أنابيب GitLab CI/CD لإصدار ما، فإنها تمرر القيم التالية:

ترفض GitHub المدخلات التي لا يعلن عنها سير العمل. لذلك ترسل Coroid coroid_version، coroid_build_number و coroid_release_name فقط إلى سير عمل يدرجها. يمكنك تعريفها كخيارات اختيارية:

on:
  workflow_dispatch:
    inputs:
      coroid_release_id: { required: true }
      coroid_attempt_id: { required: true }
      coroid_commit_sha: { required: true }
      coroid_environment: { required: true }
      coroid_version: { required: false }
      coroid_build_number: { required: false }
      coroid_release_name: { required: false }

jobs:
  deploy:
    runs-on: ubuntu-latest
    env:
      APP_VERSION: ${{ inputs.coroid_version || '0.0.0-dev' }}
      APP_BUILD_NUMBER: ${{ inputs.coroid_build_number || '0' }}
      APP_COMMIT: ${{ inputs.coroid_commit_sha || github.sha }}

ترسل GitLab القيم كمتغيرات، لذا لا حاجة للإعلان عنها:

deploy:
  script:
    - export APP_VERSION="${COROID_VERSION:-0.0.0-dev}"
    - export APP_BUILD_NUMBER="${COROID_BUILD_NUMBER:-0}"
    - export APP_COMMIT="${COROID_COMMIT_SHA:-$CI_COMMIT_SHA}"

يمكن لخط الأنابيب الذي يعمل بشكل مستقل استخدام قيمه الخاصة. ما عليك سوى الإبلاغ عن رقم الإصدار الذي نشرته، كما هو موضح أدناه، حتى يظهر في الإصدار.

كتابة ملف بيانات الإصدار#

أبسط طريقة تنجح على جميع المنصات هي كتابة ملف صغير أثناء عملية البناء وقراءته في أي مكان يُعرض فيه رقم الإصدار:

cat > release.json <<EOF
{
  "version": "$APP_VERSION",
  "buildNumber": "$APP_BUILD_NUMBER",
  "commitSha": "$APP_COMMIT",
  "releaseName": "${COROID_RELEASE_NAME:-}",
  "environment": "${COROID_ENVIRONMENT:-local}"
}
EOF

بالنسبة لتطبيق ويب أو خدمة، قم بخدمة الملف في /version.json. كما يوفر ذلك لـ Coroid عنوان URL للتحقق منه (انظر أدناه).

وصفات#

تطبيقات الويب (Next.js، Vite)#

يجب ضبط القيم التي يحتاجها المتصفح عند بناء الحزمة:

NEXT_PUBLIC_APP_VERSION="$APP_VERSION" NEXT_PUBLIC_APP_COMMIT="$APP_COMMIT" npm run build
VITE_APP_VERSION="$APP_VERSION" npm run build

عرض process.env.NEXT_PUBLIC_APP_VERSION أو import.meta.env.VITE_APP_VERSION في التذييل أو شاشة حول البرنامج، ونسخ release.json إلى مجلد عام قبل عملية البناء.

الخوادم وواجهات برمجة التطبيقات#

قراءة القيم عند بدء التشغيل والرد على نقطة نهاية رقم الإصدار:

app.get('/version.json', (_request, response) => {
  response.json({
    version: process.env.APP_VERSION,
    buildNumber: process.env.APP_BUILD_NUMBER,
    commitSha: process.env.APP_COMMIT,
  });
});

صور Docker#

مرر القيم كوسائط بناء وسمّ الصورة، حتى يعرف كل من الحاوية العاملة وسجل الصور رقم الإصدار:

ARG APP_VERSION=0.0.0-dev
ARG APP_COMMIT=unknown
ENV APP_VERSION=$APP_VERSION APP_COMMIT=$APP_COMMIT
LABEL org.opencontainers.image.version=$APP_VERSION \
      org.opencontainers.image.revision=$APP_COMMIT

docker build --build-arg APP_VERSION="$APP_VERSION" --build-arg APP_COMMIT="$APP_COMMIT" .

نظام iOS#

تقرأ Xcode رقم الإصدار المعروض في متجر التطبيقات من MARKETING_VERSION ورقم البناء من CURRENT_PROJECT_VERSION:

xcodebuild -scheme App -configuration Release archive \
  MARKETING_VERSION="$APP_VERSION" \
  CURRENT_PROJECT_VERSION="$APP_BUILD_NUMBER"

باستخدام fastlane، استخدم increment_version_number(version_number: ENV["APP_VERSION"]) و increment_build_number(build_number: ENV["APP_BUILD_NUMBER"]).

أندرويد#

اقرأ القيم الموجودة في app/build.gradle.kts:

android {
    defaultConfig {
        versionName = System.getenv("APP_VERSION") ?: "0.0.0-dev"
        versionCode = (System.getenv("APP_BUILD_NUMBER") ?: "1").toInt()
    }
}

BuildConfig.VERSION_NAME ثم يعرض الإصدار داخل التطبيق.

فلاتر#

flutter build appbundle --build-name="$APP_VERSION" --build-number="$APP_BUILD_NUMBER"
flutter build ipa --build-name="$APP_VERSION" --build-number="$APP_BUILD_NUMBER"

إكسبو ورياكت ناتيف#

اقرأ القيم الموجودة في app.config.js:

export default {
  expo: {
    version: process.env.APP_VERSION ?? '0.0.0-dev',
    ios: { buildNumber: process.env.APP_BUILD_NUMBER ?? '1' },
    android: { versionCode: Number(process.env.APP_BUILD_NUMBER ?? 1) },
  },
};

أبلغ عن الإصدار الذي قمت بنشره#

يمكن لحدث النشر أن يوضح الإصدار ورقم البناء الذي تم نشره. أضف version و buildNumber إلى الحدث الذي ترسله أداة النشر الخاصة بك مسبقًا:

{
  "schemaVersion": 1,
  "eventId": "ci:run-812:production:succeeded",
  "providerRunId": "run-812",
  "projectId": "<project-uuid>",
  "environmentKey": "production",
  "repository": "owner/repository",
  "commitSha": "0123456789abcdef0123456789abcdef01234567",
  "status": "succeeded",
  "occurredAt": "2026-09-28T12:00:00Z",
  "version": "1.4.0",
  "buildNumber": "42"
}

إذا كانت أداة النشر الخاصة بالمشروع تقوم بتعيين الإصدارات، فإن الإصدار يأخذ الإصدار المُبلغ عنه. وإلا، فإن صفحة الإصدار تعرض الإصدار المُبلغ عنه وتشير إلى اختلافه عن الإصدار. بالنسبة لمشروع مضيف على Coroid، قم بضبط repository ليصبح معرف المشروع. أحداث النشر وإعدادات CI يشرح باقي تفاصيل الحدث.

تحقق من ما يتم تشغيله#

خصص لكل بيئة عنوان URL للإصدار، مثل https://app.example.com/version.json. بعد نجاح عملية النشر، تقوم Coroid بفتح العنوان URL والبحث عن رمز الالتزام أو الإصدار. يجب أن يتطابق رمز الالتزام المُبلغ عنه مع التزام الإصدار؛ وإلا يجب أن يتطابق الإصدار. تستمر Coroid في التحقق لمدة عشر دقائق أثناء اكتمال عملية النشر، ثم تعرض مُتحقَّق منه، إصدار مختلف أو غير قابل للوصول تحت ما يتم تشغيله على صفحة الإصدار.

يجب أن يستخدم العنوان URL بروتوكول HTTPS وعنوانًا عامًا. لا تقوم Coroid بمتابعة عمليات إعادة التوجيه وتقرأ ما يصل إلى 64 كيلوبايت.

دع Coroid يقوم بإعداده#

قم بإعداد وسم الإصدار على شاشة إعدادات الإصدار يفتح عملاً جديدًا يحتوي على طلب مُعد خصيصًا للمكتبة التي يكتشفها المشروع. تقوم أداة ذكية بقراءة القيم المذكورة أعلاه أثناء عملية البناء، ثم تعرض الإصدار داخل التطبيق، وتكتب release.json، وتحدد مدخلات سير العمل وتوثقها في ملف README. قم بمراجعة الطلب، ثم تابع العمل عليه كأي مهمة أخرى.

ذات صلة#

• إعدادات الإصدار
• أحداث النشر وإعدادات CI
• إصدارات