Convex

يُربط Convex برمز وصول فريق منشأ في لوحة تحكم Convex. رمز وصول الفريق محصور في فريق واحد بالضبط، فيربط رمز واحد فريقاً واحداً. تُشفَّر الرموز قبل تخزينها، ولا يراها الوكيل أبداً.

1. افتح لوحة تحكم Convex، وانتقل إلى Team Settings → Access Tokens.
2. انقر Create access token وانسخ قيمة الرمز.
3. الصق الرمز في Polylane.
4. يتحقق Polylane من الرمز ويبدأ المزامنة.

يكتشف Polylane مشاريعك، وداخل كل واحد منها، عمليات نشره السحابية: نشر الإنتاج إضافة إلى أي عمليات نشر للمعاينة والتطوير والمخصصة، مع مناطقها وعناوين URL وفئات النشر.

تمنح رموز وصول الفريق حق الإدارة على الفريق. تقرأ المزامنة مشاريعك وعمليات نشرك برمز الفريق. حين يقرأ الوكيل أو المراقبة في الخلفية سجلات دوال أو مقاييس نشر ما، يُصدر Polylane مفتاح نشر قصير الأمد محصوراً في تلك القراءة فقط (عرض السجلات أو عرض المقاييس)، ويستخدمه للاستدعاء الواحد، ويحذفه فور انتهائه، فلا يعيش كل مفتاح إلا بقدر القراءة التي يخدمها. كل ما يقرؤه Polylane يقع على سطح الإدارة: قوائم المشاريع وعمليات النشر، وسجلات الدوال، ومقاييس النشر.

استكشاف الأخطاء

خطأ "Not a team access token"

• لا تستطيع الرموز المحصورة في مشروع ومفاتيح النشر سرد مشاريع الفريق؛ أنشئ الرمز تحت Team Settings → Access Tokens.
• تحقق من أن الرمز لم يُحذف في لوحة تحكم Convex.

موارد مفقودة

• تعمل عمليات النشر المحلية على أجهزة المطورين الفردية ولا تُزامَن عن قصد.
• لا يعرض المشروع المنشأ من دون نشر أي عمليات نشر حتى أول نشر.
• أطلق مزامنة يدوية للتحديث قبل التمرير المجدول التالي.

سجلات التدقيق

• يحصر Convex API سجلات التدقيق خلف الخطط المدفوعة. في فريق مجاني، تعيد قراءات سجلات التدقيق خطأً واضحاً ويعود الوكلاء إلى سجلات الدوال ومخطط السياق.

الفصل

افصل الحساب في Polylane، ثم احذف رمز الوصول من إعدادات فريق Convex الخاص بك.

لا يحتاج ربط Convex إلى متصفح: نقطة النهاية نفسها التي تستدعيها وحدة التحكم تناسب مهمة CI. ينشئ طلب POST موثَّق واحد الاتصال ويبدأ المزامنة الأولى.

المتطلبات الأساسية

• مفتاح API من Polylane بنطاقَي cloud_accounts:write وcloud_accounts:read. انظر مفاتيح API وOAuth.
• معرّف مساحة عملك، الذي يبدأ بـ ws_. اقرأه من GET /v1/workspaces بالمفتاح نفسه.
• رمز وصول فريق من Convex من Team Settings → Access Tokens.

إنشاء الاتصال

curl -X POST https://api.polylane.com/v1/cloud_accounts \
  -H "x-api-key: $POLYLANE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "provider": "convex",
    "workspaceId": "ws_0abc123",
    "token": "<team-access-token>"
  }'

رمز وصول الفريق محصور في فريق واحد بالضبط، فيربط استدعاء واحد فريقاً واحداً.

تسرد الاستجابة ما رُبط، مع المزامنة الأولى جارية أصلاً. مختصرة إلى الحقلين اللذين تقرؤهما بقية التدفق:

{
  "success": true,
  "result": {
    "provider": "convex",
    "accounts": [{ "id": "acc_34gky74ibc92h8t2efn8csrh", "status": "syncing" }],
    "failures": []
  }
}

يقع الحساب المربوط أصلاً في failures بدلاً من accounts، فلا يكرر تكرار الاستدعاء اتصالاً أبداً.

انتظار المزامنة الأولى

استطلع كل حساب مُعاد عبر id الخاص به حتى تصل status إلى ready (‏new عند التسجيل، وsyncing أثناء تدفق الموارد):

until [ "$(curl -s "https://api.polylane.com/v1/cloud_accounts/$WORKSPACE_ID/$ACCOUNT_ID" \
  -H "x-api-key: $POLYLANE_API_KEY" | jq -r '.result.status')" = "ready" ]; do
  sleep 15
done

أعطِ الحلقة موعداً نهائياً ليُفشل الربط الفاشل المهمة بدلاً من تعليقها. وبعد أن يصبح الحساب ready، تكون موارده في Topology ويكون Polylane قد بدأ فحصه الأول.

الفصل من API

يوقف حذف الاتصال كل مزامنة وفحص ويحذف بيانات الاعتماد التي احتفظ بها Polylane. يحتاج الاستدعاء إلى نطاق cloud_accounts:delete:

curl -X DELETE "https://api.polylane.com/v1/cloud_accounts/$WORKSPACE_ID/$ACCOUNT_ID" \
  -H "x-api-key: $POLYLANE_API_KEY"

ثم ألغِ بيانات اعتماد Convex على جانب المزود، كما هو موضح تحت الفصل أدناه.