airflow
Apache Airflow 2.10.3
يعد Apache Airflow (أو ببساطة Airflow) نظامًا أساسيًا لتأليف مسارات العمل وجدولتها ومراقبتها برمجيًا.
عندما يتم تعريف سير العمل على أنه تعليمات برمجية، فإنه يصبح أكثر قابلية للصيانة والإصدار والاختبار والتعاون.
استخدم Airflow لتأليف سير العمل كرسوم بيانية غير دورية موجهة (DAGs) للمهام. يقوم برنامج جدولة Airflow بتنفيذ مهامك على مجموعة من العمال مع اتباع التبعيات المحددة. تجعل الأدوات المساعدة لسطر الأوامر الغنية إجراء العمليات الجراحية المعقدة على DAGs أمرًا سهلاً. تعمل واجهة المستخدم الغنية على تسهيل تصور خطوط الأنابيب قيد التشغيل في الإنتاج ومراقبة التقدم واستكشاف المشكلات وإصلاحها عند الحاجة.
جدول المحتويات
يعمل تدفق الهواء بشكل أفضل مع عمليات سير العمل التي تكون في الغالب ثابتة ومتغيرة ببطء. عندما يتشابه هيكل DAG من تشغيل إلى آخر، فإنه يوضح وحدة العمل والاستمرارية. وتشمل المشاريع المماثلة الأخرى لويجي وأوزي وأزكابان.
يستخدم تدفق الهواء بشكل شائع لمعالجة البيانات، ولكن لديه رأي مفاده أن المهام يجب أن تكون غير فعالة (أي أن نتائج المهمة ستكون هي نفسها، ولن تنشئ بيانات مكررة في نظام الوجهة)، ويجب ألا تمرر كميات كبيرة من البيانات من مهمة إلى أخرى (على الرغم من أنه يمكن للمهام تمرير البيانات التعريفية باستخدام ميزة XCom الخاصة بـ Airflow). بالنسبة للمهام ذات الحجم الكبير والتي تتطلب بيانات مكثفة، فإن أفضل الممارسات هي تفويض الخدمات الخارجية المتخصصة في هذا النوع من العمل.
لا يعد Airflow حلاً للتدفق، ولكنه غالبًا ما يستخدم لمعالجة البيانات في الوقت الفعلي، وسحب البيانات من التدفقات على دفعات.
يتم اختبار Apache Airflow باستخدام:
| الإصدار الرئيسي (ديف) | الإصدار المستقر (2.10.3) | |
|---|---|---|
| بايثون | 3.9، 3.10، 3.11، 3.12 | 3.8، 3.9، 3.10، 3.11، 3.12 |
| منصة | AMD64/ARM64(*) | AMD64/ARM64(*) |
| كوبيرنيتيس | 1.28، 1.29، 1.30، 1.31 | 1.27، 1.28، 1.29، 1.30 |
| PostgreSQL | 13، 14، 15، 16، 17 | 12، 13، 14، 15، 16 |
| ماي إس كيو إل | 8.0، 8.4، الابتكار | 8.0، 8.4، الابتكار |
| سكليتي | 3.15.0+ | 3.15.0+ |
* التجريبية
ملاحظة : لم يتم اختبار أو التوصية بـ MariaDB.
ملاحظة : يتم استخدام SQLite في اختبارات تدفق الهواء. لا تستخدمه في الإنتاج. نوصي باستخدام أحدث إصدار ثابت من SQLite للتطوير المحلي.
ملحوظة : يمكن تشغيل Airflow حاليًا على أنظمة التشغيل المتوافقة مع POSIX. من أجل التطوير، يتم اختباره بانتظام على توزيعات Linux الحديثة إلى حد ما والإصدارات الحديثة من نظام التشغيل MacOS. على نظام Windows، يمكنك تشغيله عبر WSL2 (نظام Windows الفرعي لنظام Linux 2) أو عبر Linux Containers. يتم تتبع العمل على إضافة دعم Windows عبر #10388، لكنه ليس أولوية عالية. يجب عليك فقط استخدام التوزيعات المستندة إلى Linux كبيئة تنفيذ "إنتاجية" لأن هذه هي البيئة الوحيدة المدعومة. التوزيعة الوحيدة المستخدمة في اختبارات CI لدينا والمستخدمة في صورة DockerHub التي يديرها المجتمع هي Debian Bookworm .
قم بزيارة وثائق موقع Airflow الرسمي (أحدث إصدار ثابت ) للمساعدة في تثبيت Airflow، أو البدء، أو الاطلاع على برنامج تعليمي أكثر اكتمالاً.
ملاحظة: إذا كنت تبحث عن وثائق للفرع الرئيسي (أحدث فرع تطوير): يمكنك العثور عليها على s.apache.org/airflow-docs.
لمزيد من المعلومات حول مقترحات تحسين تدفق الهواء (AIPs)، قم بزيارة Airflow Wiki.
وثائق المشاريع التابعة مثل حزم الموفرين، صورة Docker، مخطط Helm، ستجدها في فهرس الوثائق.
ننشر Apache Airflow كحزمة apache-airflow في PyPI. ومع ذلك، قد يكون تثبيته أمرًا صعبًا في بعض الأحيان لأن Airflow عبارة عن مكتبة وتطبيق. عادةً ما تبقي المكتبات تبعياتها مفتوحة، وعادةً ما تقوم التطبيقات بتثبيتها، ولكن لا ينبغي لنا أن نفعل أيًا منهما أو نفعل كليهما في وقت واحد. قررنا إبقاء تبعياتنا مفتوحة قدر الإمكان (في pyproject.toml ) حتى يتمكن المستخدمون من تثبيت إصدارات مختلفة من المكتبات إذا لزم الأمر. هذا يعني أن pip install apache-airflow لن يعمل من وقت لآخر أو سيؤدي إلى تثبيت Airflow غير قابل للاستخدام.
ومع ذلك، للحصول على تثبيت قابل للتكرار، فإننا نحتفظ بمجموعة من ملفات القيود "المعروفة للعمل" في الفروع اليتيمة constraints-main constraints-2-0 . نحن نحتفظ بملفات القيود "المعروفة للعمل" بشكل منفصل لكل إصدار بايثون رئيسي/ثانوي. يمكنك استخدامها كملفات قيد عند تثبيت Airflow من PyPI. لاحظ أنه يتعين عليك تحديد علامة/إصدار/فرع Airflow الصحيح وإصدارات Python في عنوان URL.
ملاحظة: يتم حاليًا دعم تثبيت
pipفقط رسميًا.
على الرغم من أنه من الممكن تثبيت Airflow باستخدام أدوات مثل Poetry أو pip-tools، إلا أنها لا تشترك في نفس سير العمل مثل pip - خاصة عندما يتعلق الأمر بإدارة القيود مقابل إدارة المتطلبات. التثبيت عبر Poetry أو pip-tools غير مدعوم حاليًا.
هناك مشكلات معروفة في bazel قد تؤدي إلى تبعيات دائرية عند استخدامه لتثبيت Airflow. يرجى التبديل إلى pip إذا واجهت مثل هذه المشاكل. يعمل مجتمع Bazel على حل المشكلة في this PR <https://github.com/bazelbuild/rules_python/pull/1166> _ لذلك قد تتعامل الإصدارات الأحدث من bazel مع هذه المشكلة.
إذا كنت ترغب في تثبيت Airflow باستخدام تلك الأدوات، فيجب عليك استخدام ملفات القيد وتحويلها إلى التنسيق وسير العمل المناسبين اللذين تتطلبهما أداتك.
pip install ' apache-airflow==2.10.3 '
--constraint " https://raw.githubusercontent.com/apache/airflow/constraints-2.10.3/constraints-3.9.txt "pip install ' apache-airflow[postgres,google]==2.10.3 '
--constraint " https://raw.githubusercontent.com/apache/airflow/constraints-2.10.3/constraints-3.9.txt "للحصول على معلومات حول تثبيت حزم الموفر، تحقق من الموفرين.
Apache Airflow هو مشروع تابع لمؤسسة Apache Software (ASF)، وإصدارات كود المصدر الرسمية الخاصة بنا:
وفقًا لقواعد ASF، يجب أن تكون الحزم المصدرية التي تم إصدارها كافية للمستخدم لإنشاء الإصدار واختباره بشرط أن يكون لديه إمكانية الوصول إلى النظام الأساسي والأدوات المناسبة.
هناك طرق أخرى لتثبيت واستخدام Airflow. هذه أساليب "ملائمة" - فهي ليست "إصدارات رسمية" كما هو منصوص عليه في ASF Release Policy ، ولكن يمكن استخدامها من قبل المستخدمين الذين لا يريدون إنشاء البرنامج بأنفسهم.
هذه هي - حسب ترتيب الطرق الأكثر شيوعًا لتثبيت Airflow:
pip القياسيةdocker ، واستخدامها في Kubernetes، وHelm Charts، docker-compose ، و docker swarm ، وما إلى ذلك. يمكنك قراءة المزيد حول استخدام الصور وتخصيصها وتوسيعها في أحدث المستندات، ومعرفة التفاصيل حول العناصر الداخلية في وثيقة الصور.كل هذه القطع الأثرية ليست إصدارات رسمية، ولكن تم إعدادها باستخدام مصادر تم إصدارها رسميًا. بعض هذه العناصر هي عناصر "تطوير" أو "ما قبل الإصدار"، وقد تم تمييزها بوضوح على هذا النحو وفقًا لسياسة ASF.
DAGs : نظرة عامة على جميع DAGs في بيئتك.
الشبكة : تمثيل شبكي لـ DAG يمتد عبر الزمن.
الرسم البياني : تصور تبعيات DAG وحالتها الحالية لتشغيل معين.
مدة المهمة : إجمالي الوقت المستغرق في مهام مختلفة مع مرور الوقت.
جانت : مدة وتداخل DAG.
الكود : طريقة سريعة لعرض الكود المصدري لـ DAG.
اعتبارًا من Airflow 2.0.0، نحن ندعم نهج SemVer الصارم لجميع الحزم التي تم إصدارها.
هناك عدد قليل من القواعد المحددة التي اتفقنا عليها والتي تحدد تفاصيل إصدار الحزم المختلفة:
google 4.1.0 و amazon 3.0.3 مع Airflow 2.1.2 . إذا كانت هناك حدود للتبعيات المتبادلة بين مقدمي الخدمة وحزم Airflow، فهي موجودة في مقدمي الخدمة على أنها قيود install_requires . نحن نهدف إلى الحفاظ على التوافق العكسي بين مقدمي الخدمة وجميع إصدارات Airflow 2 التي تم إصدارها مسبقًا، ولكن قد تكون هناك في بعض الأحيان تغييرات جذرية قد تجعل بعض مقدمي الخدمة أو جميعهم لديهم الحد الأدنى من إصدار Airflow المحدد.دورة حياة إصدار Apache Airflow:
| إصدار | التصحيح الحالي/الثانوي | ولاية | الإصدار الأول | دعم محدود | موسوعة الحياة/منتهية |
|---|---|---|---|---|---|
| 2 | 2.10.3 | المدعومة | 17 ديسمبر 2020 | سيتم تحديده لاحقًا | سيتم تحديده لاحقًا |
| 1.10 | 1.10.15 | موسوعة الحياة | 27 أغسطس 2018 | 17 ديسمبر 2020 | 17 يونيو 2021 |
| 1.9 | 1.9.0 | موسوعة الحياة | 03 يناير 2018 | 27 أغسطس 2018 | 27 أغسطس 2018 |
| 1.8 | 1.8.2 | موسوعة الحياة | 19 مارس 2017 | 03 يناير 2018 | 03 يناير 2018 |
| 1.7 | 1.7.1.2 | موسوعة الحياة | 28 مارس 2016 | 19 مارس 2017 | 19 مارس 2017 |
سيتم دعم إصدارات الدعم المحدودة من خلال الأمان وإصلاح الأخطاء الحرجة فقط. لن تحصل إصدارات EOL على أي إصلاحات أو دعم. نوصي دائمًا بأن يقوم جميع المستخدمين بتشغيل أحدث إصدار ثانوي متاح لأي إصدار رئيسي قيد الاستخدام. نوصي بشدة بالترقية إلى أحدث إصدار رئيسي من Airflow في أقرب وقت مناسب وقبل تاريخ EOL.
اعتبارًا من Airflow 2.0، اتفقنا على قواعد معينة نتبعها لدعم Python وKubernetes. وهي تستند إلى جدول الإصدار الرسمي لـ Python وKubernetes، والذي تم تلخيصه بشكل جيد في دليل مطور Python وسياسة الانحراف لإصدار Kubernetes.
نقوم بإسقاط الدعم لإصدارات Python وKubernetes عندما تصل إلى EOL. باستثناء Kubernetes، يظل الإصدار مدعومًا بواسطة Airflow إذا استمر اثنان من موفري الخدمات السحابية الرئيسيين في تقديم الدعم له. لقد قمنا بإسقاط الدعم لإصدارات موسوعة الحياة هذه بشكل رئيسي بعد تاريخ موسوعة الحياة مباشرة، وتتم إزالته بشكل فعال عندما نصدر أول إصدار ثانوي جديد (أو رئيسي إذا لم يكن هناك إصدار ثانوي جديد) من Airflow. على سبيل المثال، بالنسبة لـ Python 3.9، فهذا يعني أننا سنسقط الدعم بشكل رئيسي بعد 27.06.2023، ولن يتوفر الدعم في الإصدار الرئيسي أو الثانوي الأول من Airflow الذي تم إصداره بعد ذلك.
نحن ندعم إصدارًا جديدًا من Python/Kubernetes بشكل رئيسي بعد إصدارها رسميًا، وبمجرد أن نجعلها تعمل في مسار CI الخاص بنا (والذي قد لا يكون فوريًا بسبب التبعيات التي تلحق بالإصدارات الجديدة من Python في الغالب) فإننا نصدر صورًا جديدة / الدعم في تدفق الهواء بناءً على إعداد CI العامل.
تمثل هذه السياسة أفضل جهد مما يعني أنه قد تكون هناك مواقف قد نقوم فيها بإنهاء الدعم مبكرًا إذا تطلبت الظروف ذلك.
يوفر مجتمع Airflow صور حاويات مجمعة بشكل ملائم يتم نشرها عندما ننشر إصدار Apache Airflow. تحتوي تلك الصور على:
إصدار صورة نظام التشغيل الأساسي هو الإصدار الثابت من دبيان. يدعم Airflow استخدام جميع الإصدارات المستقرة النشطة حاليًا - بمجرد أن تدعم جميع تبعيات Airflow البناء، ونقوم بإعداد مسار CI لإنشاء إصدار نظام التشغيل واختباره. قبل حوالي 6 أشهر من نهاية الدعم المنتظم للإصدار الثابت السابق من نظام التشغيل، يقوم Airflow بتبديل الصور التي تم إصدارها لاستخدام أحدث إصدار مدعوم من نظام التشغيل.
على سبيل المثال، تم تنفيذ التبديل من Debian Bullseye إلى Debian Bookworm قبل إصدار 2.8.0 في أكتوبر 2023 وسيكون Debian Bookworm هو الخيار الوحيد المدعوم اعتبارًا من Airflow 2.10.0.
سيستمر المستخدمون في القدرة على إنشاء صورهم باستخدام إصدارات دبيان المستقرة حتى نهاية الدعم المنتظم وبناء الصور والتحقق منها في CI الخاص بنا ولكن لم يتم تنفيذ أي اختبارات وحدة باستخدام هذه الصورة في الفرع main .
يحتوي Airflow على الكثير من التبعيات - المباشرة والانتقالية، كما أن Airflow عبارة عن مكتبة وتطبيق، لذلك يجب أن تتضمن سياساتنا المتعلقة بالتبعيات كليهما - استقرار تثبيت التطبيق، ولكن أيضًا القدرة على تثبيت إصدار أحدث من التبعيات لهؤلاء المستخدمين الذين يقومون بتطوير DAGs. لقد قمنا بتطوير النهج حيث يتم استخدام constraints للتأكد من إمكانية تثبيت تدفق الهواء بطريقة قابلة للتكرار، في حين أننا لا نقيد مستخدمينا لترقية معظم التبعيات. ونتيجة لذلك، قررنا عدم استخدام الإصدار ذي الحد الأعلى من تبعيات Airflow بشكل افتراضي، إلا إذا كانت لدينا أسباب وجيهة للاعتقاد بأن الحد الأعلى منها مطلوب بسبب أهمية التبعية بالإضافة إلى المخاطر التي تنطوي عليها ترقية تبعية معينة. نحن أيضًا نضع حدودًا أعلى للتبعيات التي نعرف أنها تسبب مشاكل.
تهتم آلية القيد الخاصة بنا بالعثور على جميع التبعيات غير ذات الحد الأعلى وترقيتها تلقائيًا (بشرط اجتياز جميع الاختبارات). ستشير حالات فشل البناء main لدينا إلى ما إذا كانت هناك إصدارات من التبعيات التي تكسر اختباراتنا - مما يشير إلى أنه يجب علينا إما ربطها بشكل علوي أو أنه يجب علينا إصلاح التعليمات البرمجية/الاختبارات الخاصة بنا لمراعاة التغييرات الأولية من تلك التبعيات.
عندما نضع حدًا أعلى لمثل هذه التبعية، يجب علينا دائمًا التعليق على سبب قيامنا بذلك - أي يجب أن يكون لدينا سبب وجيه وراء كون التبعية ذات حد أعلى. ويجب أن نذكر أيضًا ما هو شرط إزالة الربط.
يتم الحفاظ على هذه التبعيات في pyproject.toml .
هناك عدد قليل من التبعيات التي قررنا أنها مهمة بما يكفي للحد منها افتراضيًا، حيث من المعروف أنها تتبع نظام إصدار يمكن التنبؤ به، ونحن نعلم أن الإصدارات الجديدة من تلك التبعيات من المرجح جدًا أن تجلب تغييرات جذرية. نحن نلتزم بالمراجعة المنتظمة ومحاولة الترقية إلى الإصدارات الأحدث من التبعيات عند إصدارها، ولكن هذه عملية يدوية.
التبعيات الهامة هي:
SQLAlchemy : الحد الأعلى لإصدار MINOR محدد (من المعروف أن SQLAlchemy يزيل حالات الإهمال ويقدم تغييرات جذرية خاصة أن دعم قواعد البيانات المختلفة يختلف ويتغير بسرعات مختلفة)Alembic : من المهم التعامل مع هجراتنا بطريقة يمكن التنبؤ بها وفعالة. تم تطويره مع SQLAlchemy. تجربتنا مع Alembic هي أنها مستقرة جدًا في الإصدار MINORFlask : نحن نستخدم Flask باعتباره العمود الفقري لواجهة مستخدم الويب وواجهة برمجة التطبيقات (API). نحن نعلم أن الإصدار الرئيسي من Flask من المحتمل جدًا أن يقدم تغييرات جذرية عبر تلك التغييرات، لذا فإن قصره على الإصدار الرئيسي أمر منطقيwerkzeug : من المعروف أن المكتبة تسبب مشاكل في الإصدارات الجديدة. إنها مقترنة بإحكام بمكتبات Flask، ويجب علينا تحديثها معًاcelery : يعد الكرفس عنصرًا حاسمًا في تدفق الهواء لأنه يستخدم في CeleryExecutor (وما شابه). يتبع Celery SemVer، لذا يجب أن نربطه بالإصدار الرئيسي التالي. أيضًا، عندما نقوم بتحديث الإصدار العلوي من المكتبة، يجب أن نتأكد من تحديث الحد الأدنى من إصدار Airflow لموفر Celery.kubernetes : يعد Kubernetes مكونًا حاسمًا في Airflow حيث يتم استخدامه في KubernetesExecutor (وما شابه). تتبع مكتبة Kubernetes Python SemVer، لذا يجب أن نربطها بالإصدار الرئيسي التالي. أيضًا، عند تحديث الإصدار العلوي من المكتبة، يجب أن نتأكد من تحديث الحد الأدنى من إصدار Airflow لموفر Kubernetes.الجزء الرئيسي من Airflow هو Airflow Core، ولكن قوة Airflow تأتي أيضًا من عدد من مقدمي الخدمة الذين يقومون بتوسيع الوظائف الأساسية ويتم إصدارهم بشكل منفصل، حتى لو احتفظنا بهم (في الوقت الحالي) في نفس monorepo للراحة. يمكنك قراءة المزيد عن مقدمي الخدمة في وثائق مقدمي الخدمة. لدينا أيضًا مجموعة من السياسات التي تم تنفيذها للحفاظ على مقدمي الخدمات الذين يديرهم المجتمع وإطلاق سراحهم، بالإضافة إلى النهج الخاص بالمجتمع مقابل موفري الطرف الثالث في مستند مقدمي الخدمة.
يتم الاحتفاظ بهذه extras وتبعيات providers في provider.yaml لكل مزود.
افتراضيًا، لا ينبغي لنا أن نتجاوز التبعيات ذات الحد الأعلى لمقدمي الخدمة، ولكن قد يقرر مشرف كل مزود إضافة حدود إضافية (وتبريرها بالتعليق).
هل تريد المساعدة في بناء Apache Airflow؟ راجع دليل المساهمين لدينا للحصول على نظرة عامة شاملة حول كيفية المساهمة، بما في ذلك تعليمات الإعداد ومعايير الترميز وإرشادات طلب السحب.
إذا كنت لا تستطيع الانتظار للمساهمة، وتريد البدء في أسرع وقت ممكن، فاطلع على البداية السريعة للمساهمة هنا!
تم توضيح صور Docker (الحاوية) الرسمية لـ Apache Airflow في الصور.
+1s الخاصة بكل من أعضاء PMC والملتزمين تعتبر تصويتًا ملزمًا. نحن نعرف حوالي 500 منظمة تستخدم Apache Airflow (ولكن من المحتمل أن يكون هناك الكثير منها) في البرية.
إذا كنت تستخدم Airflow - فلا تتردد في إجراء علاقات عامة لإضافة مؤسستك إلى القائمة.
إن Airflow هو عمل المجتمع، ولكن الملتزمين/المشرفين الأساسيين مسؤولون عن مراجعة ودمج العلاقات العامة بالإضافة إلى توجيه المحادثات حول طلبات الميزات الجديدة. إذا كنت ترغب في أن تصبح مشرفًا، فيرجى مراجعة متطلبات متعهد Apache Airflow.
في كثير من الأحيان، ستشاهد مشكلة تم تعيينها لمرحلة رئيسية محددة في إصدار Airflow، أو PR الذي تم دمجه في الفرع الرئيسي وقد تتساءل عن الإصدار الذي سيتم إصدار العلاقات العامة (العلاقات العامة) المدمجة فيه أو الإصدار الذي سيتم إصلاح المشكلات فيه في. الجواب على هذا هو كالعادة، ويعتمد على سيناريوهات مختلفة. الجواب مختلف بالنسبة للعلاقات العامة والقضايا.
لإضافة القليل من السياق، فإننا نتبع مخطط إصدار Semver كما هو موضح في عملية إصدار Airflow. تم شرح المزيد من التفاصيل بالتفصيل في هذا الملف التمهيدي ضمن فصل الإصدارات الدلالية، ولكن باختصار، لدينا إصدارات MAJOR.MINOR.PATCH من Airflow.
MAJOR في حالة حدوث تغييراتMINOR عند إضافة ميزات جديدةPATCH عندما تكون هناك إصلاحات للأخطاء وتغييرات للمستندات فقط بشكل عام، نقوم بإصدار إصدارات MINOR من Airflow من فرع يحمل اسم الإصدار MINOR. على سبيل المثال، يتم إصدار الإصدارات 2.7.* من الفرع v2-7-stable ويتم إصدار الإصدارات 2.8.* من الفرع v2-8-stable ، وما إلى ذلك.
في معظم الأوقات خلال دورة الإصدار لدينا، عندما لا يتم إنشاء فرع فرع MINOR التالي بعد، ستجد جميع المستفيدين الرئيسيين الذين تم دمجهم في main (ما لم يتم إعادتهم)، طريقهم إلى الإصدار MINOR التالي. على سبيل المثال، إذا كان الإصدار الأخير هو 2.7.3 ولم يتم إنشاء الفرع v2-8-stable بعد، فإن الإصدار MINOR التالي هو 2.8.0 وسيتم إصدار جميع المستفيدين الرئيسيين المدمجين في main في 2.8.0 . ومع ذلك، يمكن اختيار بعض البرامج العامة (إصلاحات الأخطاء وتغييرات المستندات فقط) عند دمجها إلى فرع MINOR الحالي وإصدارها في إصدار PATCHLEVEL التالي. على سبيل المثال، إذا تم إصدار 2.8.1 بالفعل ونحن نعمل على 2.9.0dev ، فإن وضع علامة PR على 2.8.2 يعني أنه سيتم اختياره بشكل الكرز لفرع v2-8-test وإصداره في 2.8.2rc1 ، وأخيرا في 2.8.2 .
عندما نستعد للإصدار MINOR التالي، نقوم بقطع فرع v2-*-test و v2-*-stable الجديد ونجهز إصدارات alpha beta للإصدار MINOR التالي، وستظل PRs المدمجة في main تصدر في الإصدار MINOR التالي حتى يتم قطع نسخة rc . يحدث هذا بسبب إعادة بناء الفروع v2-*-test و v2-*-stable على الجزء العلوي من main عند إعداد الإصدارات beta التالية وإصدارات rc . على سبيل المثال، عندما قمنا بقص الإصدار 2.10.0beta1 ، فإن أي شيء تم دمجه في الإصدار الرئيسي قبل إصدار 2.10.0rc1 ، سيجد طريقه إلى 2.10.0rc1.
بعد ذلك، بمجرد أن نجهز مرشح RC الأول للإصدار MINOR، نتوقف عن نقل الفروع v2-*-test و v2-*-stable وسيتم إصدار PRs المدمجة في الإصدار الرئيسي في الإصدار MINOR التالي. ومع ذلك، يمكن انتقاء بعض البرامج العامة (إصلاحات الأخطاء وتغييرات المستند فقط) عند دمجها إلى فرع MINOR الحالي وإصدارها في إصدار PATCHLEVEL التالي - على سبيل المثال عندما يكون الإصدار الأخير من فرع v2-10-stable هو 2.10.0rc1 ، يمكن تمييز بعض العلاقات العامة من main على أنها 2.10.0 من قبل الملتزمين، وسيحاول مدير الإصدار انتقاءهم في فرع الإصدار. إذا نجحت، فسيتم إصدارها في 2.10.0rc2 وبعد ذلك في 2.10.0 . وينطبق هذا أيضًا على إصدارات PATCHLEVEL اللاحقة. على سبيل المثال، عندما يتم إصدار 2.10.1 بالفعل، فإن تحديد PR بـ 2.10.2 سيعني أنه سيتم اختياره بشكل الكرز إلى فرع v2-10-stable وإصداره في 2.10.2rc1 وفي النهاية في 2.10.2 .
يتم اتخاذ القرار النهائي بشأن قطف الكرز من قبل مدير الإصدار.
إن وضع علامة على المشكلات باستخدام حدث رئيسي مختلف بعض الشيء. لا يقوم القائمون على الصيانة بوضع علامة على المشكلات بمعلم رئيسي عادةً، وعادة ما يتم وضع علامة عليها فقط في العلاقات العامة. إذا تم دمج العلاقات العامة المرتبطة بالمشكلة (و"إصلاحها") وإصدارها في إصدار محدد باتباع العملية الموضحة أعلاه، فسيتم إغلاق المشكلة تلقائيًا، ولن يتم تعيين أي معلم رئيسي للمشكلة، وتحتاج إلى التحقق من العلاقات العامة التي تم إصلاح المشكلة لمعرفة الإصدار الذي تم إصداره فيه.
ومع ذلك، في بعض الأحيان، يقوم المشرفون بوضع علامة على المشكلات بمعلم رئيسي محدد، مما يعني أن المشكلة مهمة لتصبح مرشحًا لإلقاء نظرة عند إعداد الإصدار. نظرًا لأن هذا مشروع مفتوح المصدر، حيث يتطوع جميع المساهمين بوقتهم، فليس هناك ضمان بأنه سيتم إصلاح مشكلة معينة في إصدار معين. لا نريد تعليق الإصدار نظرًا لعدم إصلاح بعض المشكلات، لذا في مثل هذه الحالة، سيعيد مدير الإصدار تعيين هذه المشكلات التي لم يتم إصلاحها إلى الحدث الرئيسي التالي في حالة عدم إصلاحها في الوقت المناسب للإصدار الحالي. لذلك، فإن الحدث الرئيسي للمشكلة هو نية يجب النظر فيها أكثر من الوعد بإصلاحها في الإصدار.
يمكن العثور على المزيد من السياق والأسئلة الشائعة حول إصدار مستوى التصحيح في مستند ما الذي سيتم إدخاله في الإصدار التالي في مجلد dev بالمستودع.
نعم! تأكد من الالتزام بسياسات العلامات التجارية الخاصة بمؤسسة Apache وApache Airflow Brandbook. تم العثور على أحدث الشعارات في هذا الريبو وعلى موقع الويب الخاص بمؤسسة Apache Software Foundation.
تمت رعاية البنية التحتية لـ CI لـ Apache Airflow بواسطة:
