CI/CD لـ APEX باستخدام GitHub Actions

بمجرد أن يعيش تطبيق APEX في Git كملفات APEXlang، يمكن لخط أنابيب أن ينشره عنك. يبني هذا الدليل سير عمل GitHub Actions يثبّت SQLcl، ويتحقق من أن مصدر APEXlang يُترجَم دون أخطاء، ويستورد التطبيق إلى القاعدة الهدف مع كل دفع إلى main.

صدّر التطبيق كملفات APEXlang

في SQLcl، اتصل بمخطط التحليل (parsing schema) لمساحة العمل وصدّر التطبيق بصيغة APEXlang:

apex export -applicationid 100 -exptype APEXLANG -skipexportdate -dir apex -force

ينشئ SQLcl المجلد apex/<app-alias>/ (الاسم المستعار بحروف صغيرة) وفيه application.apx، وملف .apx لكل صفحة تحت pages/، وshared-components/، وdeployments/default.json الذي يحمل رقم التطبيق المستخدم عند الاستيراد. الخيار -skipexportdate يجعل التصديرات المتكررة متطابقة بايتًا ببايت، فلا يُظهر الفرق إلا التغييرات الحقيقية؛ والخيار -force يفرّغ المجلد أولًا فلا تبقى الصفحات المحذوفة. ثبّت المجلد:

git add apex/
git commit -m "feat: add status filter to orders page"
git push

خزّن الاعتمادات كأسرار

في مستودعك اذهب إلى Settings → Environments، وأنشئ بيئة باسم production، وأضف ثلاثة أسرار بيئة. هناك قيود حسب الخطة: في GitHub Free تعمل أسرار البيئة في المستودعات العامة فقط، واشتراط موافقة مراجع في المستودعات الخاصة يتطلب GitHub Enterprise. في مستودع خاص على GitHub Free، أضف الأسماء الثلاثة نفسها كأسرار مستودع (Settings → Secrets and variables → Actions) واحذف السطر environment: production.

• DB_USER — مستخدم النشر (مثل مخطط التحليل لمساحة العمل).
• DB_PASSWORD — كلمة مروره.
• DB_CONNECT — سلسلة EZConnect مثل db.example.com:1521/FREEPDB1.

سير عمل النشر

احفظ هذا في .github/workflows/deploy-apex.yml واضبط APP_DIR على المجلد الذي أنشأه SQLcl:

name: deploy-apex

on:
  push:
    branches: [main]
    paths: ["apex/**"]
  workflow_dispatch:

concurrency:
  group: deploy-apex
  cancel-in-progress: false

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production
    env:
      APP_DIR: apex/my-app
    steps:
      - uses: actions/checkout@v7

      - uses: actions/setup-java@v6
        with:
          distribution: oracle
          java-version: "25"

      - name: Install SQLcl
        run: |
          curl -sSL -o sqlcl.zip https://download.oracle.com/otn_software/java/sqldeveloper/sqlcl-latest.zip
          unzip -q sqlcl.zip
          ./sqlcl/bin/sql -V

      - name: Validate APEXlang
        run: |
          ./sqlcl/bin/sql -S /nolog <<EOF | tee validate.log
          apex validate -input $APP_DIR
          exit
          EOF
          grep -q "Validation successful." validate.log

      - name: Import app
        env:
          DB_USER: ${{ secrets.DB_USER }}
          DB_PASSWORD: ${{ secrets.DB_PASSWORD }}
          DB_CONNECT: ${{ secrets.DB_CONNECT }}
        run: |
          ./sqlcl/bin/sql -S /nolog <<EOF | tee import.log
          connect $DB_USER/"$DB_PASSWORD"@$DB_CONNECT
          apex import -input $APP_DIR
          exit
          EOF
          grep -q "Import successful." import.log

• يثبّت actions/setup-java حزمة Oracle JDK 25 التي تقدّمها Oracle بترخيص الاستخدام المجاني. ومن المقرر أن تنتقل تحديثات Oracle JDK 21 بدءًا من تحديث CPU لشهر أكتوبر 2026 (20 أكتوبر 2026) إلى ترخيص Java SE OTN. إن فضّلت Java 21 فاستخدم distribution: temurin.
• يجلب sqlcl-latest.zip أحدث SQLcl دائمًا، ويطبع sql -V الإصدار في السجل. لبناء قابل للتكرار تمامًا، نزّل ملف إصدار محدد بدلًا منه.
• الأمر apex validate فحص دون اتصال يتأكد أن APEXlang يُترجَم، لذا لا تحتاج تلك الخطوة اتصالًا ولا أسرارًا. لكنه لا يفحص اعتماداتك ولا كائنات قاعدتك: كلمة المرور الخاطئة تُفشل خطوة الاستيراد، أما الجدول أو العمود المفقود فلا تكتشفه أي من الخطوتين، ولا يظهر إلا عند تشغيل الصفحة؛ لذا أنشئ كائنات المخطط قبل الاستيراد (مثلًا بخطوة ترحيل) واختبر التطبيق سريعًا بعد النشر.
• يخرج SQLcl برمز 0 حتى عندما يبلّغ apex validate أو apex import عن أخطاء، لذا تفحص كل خطوة السجل بحثًا عن سطر النجاح وتُفشل المهمة إن غاب.
• يمرّر الـ heredoc كلمة المرور عبر الإدخال القياسي فلا تظهر في سطر الأوامر أبدًا، ولا يعيد SQLcl طباعة ذلك الإدخال. كما يُخفي GitHub قيم الأسرار في سجلات المهام. أما -S فيُخفي فقط شعار SQLcl ومحثّاته.

اختبر فهمك