مثال تنفيذ التكامل المستمر باستخدام BuildBot

(الصورة بواسطة Computerizer من Pixabay)

تحية!

اسمي Evgeny Cherkin ، أنا مبرمج فريق التطوير في شركة التعدين Polymetal .

عند بدء أي مشروع كبير ، تبدأ في التفكير: "ما البرنامج الأفضل للاستخدام في صيانته؟". يمر مشروع تكنولوجيا المعلومات قبل إصدار الإصدار التالي بمجموعة من المراحل. إنه أمر جيد عندما تكون سلسلة هذه الخطوات تلقائية. وتسمى العملية التلقائية لإطلاق نسخة جديدة من مشروع تكنولوجيا المعلومات Continuous Integration . تحولت BuildBot إلى أن تكون مساعد جيد بالنسبة لنا ، وتنفيذ هذه العملية.

في هذه المقالة ، قررت تقديم نظرة عامة على ميزات BuildBot . ما هو هذا البرنامج قادر على؟ كيف تتعامل معه وكيف تبني علاقة عمل طبيعية فعالة معه؟ يمكنك أيضًا تطبيق خبرتنا على نفسك عن طريق إنشاء خدمة تعمل على جهازك لتجميع واختبار مشروعك.

1. لماذا BuildBot؟

---

في وقت سابق على habr-e ، صادفت مقالات حول تطبيق التكامل المستمر باستخدام BuildBot . على سبيل المثال ، بدا لي هذا الأكثر إفادة. هناك مثال آخر - أبسط . يمكن أن تكون هذه المقالات محنكًا بمثال من الدليل ، وهذا بعد ، باللغة الإنجليزية. الكوبيه هي نقطة انطلاق جيدة. بعد قراءة هذه المقالات ، قد ترغب في القيام بشيء ما على BuildBot على الفور .

توقف عن ذلك! هل أي شخص حتى استخدامها في مشاريعهم؟ اتضح نعم ، لقد طبق الكثير منهم في مهامهم. يمكنك العثور على أمثلة لاستخدام BuildBot في أرشيفات كود Google.

إذن ما هو منطق الناس الذين يستخدمون buildbot ؟ بعد كل شيء ، هناك أدوات أخرى: CruiseControl و Jenkins . سأجيب بهذه الطريقة. بالنسبة لمعظم المهام ، جنكينز حقا سيكون كافيا. BuildBot ، بدوره ، أكثر قدرة على التكيف ، ويتم حل المهام هناك بسهولة كما هو الحال في جنكينز . اختر لك ولكن نظرًا لأننا نبحث عن أداة لتطوير مشروع مستهدف ، فلماذا لا نختار المشروع الذي يسمح لنا ، بدءًا من الخطوات البسيطة ، بالحصول على نظام بناء له تفاعل وواجهة فريدة.

بالنسبة لأولئك الذين يتم كتابة مشروعهم المستهدف في بيثون ، فإن السؤال الذي يطرح نفسه هو: "لماذا لا تختار نظام تكامل له واجهة واضحة من حيث اللغة المستخدمة في المشروع؟". ثم حان الوقت لتقديم فوائد BuildBot .

لذلك ، لدينا "الرباعية مفيدة". بنفسي ، قمت بتعريف الميزات الأربعة لـ BuildBot :

1. هذا إطار عمل مفتوح المصدر تحت رخصة GPL
2. هذا يستخدم بيثون كأداة تكوين ويصف الإجراءات المطلوبة.
3. هذه فرصة لتلقي استجابة من الجهاز الذي تحدث فيه المجموعة.
4. هذه هي في النهاية الحد الأدنى لمتطلبات المضيف. يتطلب النشر الثعبان والملتوية ، وليس هناك حاجة إلى آلة افتراضية أو آلة جافا.

2. مفهوم بقيادة BuildMaster

---

المركزية لبنية توزيع المهام هي BuildMaster . إنها خدمة:

• يتتبع التغييرات في شجرة مصدر المشروع
• يرسل الأوامر التي يجب أن تنفذها خدمة العامل لبناء مشروع واختباره
• يخطر المستخدمين بنتائج الإجراءات المتخذة

تم تكوين BuildMaster من خلال ملف master.cfg . هذا الملف هو في جذر BuildMaster . في وقت لاحق سوف تظهر كيف يتم إنشاء هذا الجذر. يحتوي ملف master.cfg نفسه على python ، وهو برنامج نصي يستخدم مكالمات BuildBot .

يسمى BuildBot الأكثر أهمية العامل . يمكن تشغيل هذه الخدمة على مضيف مختلف باستخدام نظام تشغيل مختلف ، أو ربما على موقع BuildMaster . يمكن أن توجد أيضًا في بيئة افتراضية مُعدة خصيصًا مع حزمها ومتغيراتها. يمكن إعداد هذه البيئات الافتراضية باستخدام أدوات python مثل vertualenv و venv .

يبث BuildMaster الأوامر إلى كل عامل يقوم بدوره بتنفيذها. وهذا يعني ، أن عملية بناء المشروع واختباره يمكن أن تذهب إلى العامل تحت Windows وعلى عامل آخر تحت نظام لينكس.

يحدث الخروج من التعليمات البرمجية المصدر للمشروع على كل عامل .

3. التثبيت

---

لذلك دعونا نذهب. سأستخدم Ubuntu 18.04 كمضيف. على ذلك ، سأضع BuildMaster واحدًا وعاملًا واحدًا. ولكن أولاً ستحتاج إلى تثبيت python3.7:

sudo apt-get update sudo apt-get install python3.7 

بالنسبة لأولئك الذين يحتاجون إلى python3.7.2 بدلاً من 3.7.1 ، يمكنك القيام بما يلي:

 sudo apt-get update sudo apt-get software-properties-common sudo add-apt-repository ppa:deadsnakes/ppa sudo apt-get install python3.7 sudo ln -fs /usr/bin/python3.7 /usr/bin/python3 pip3 install --upgrade pip 

الخطوة التالية هي تثبيت Twited و BuildBot ، وكذلك الحزم التي تتيح وظائف BuildBot إضافية.

 /*   sudo        /usr/local/lib/python3.7/dist-packages*/ #     Worker- sudo pip install twisted # twisted sudo pip install buildbot #BuildMaster #  pip install pysqlite3 #  sqllite    pip install jinja2 #framework  django,  web     pip install autobahn #Web c   BuildMaster->Worker pip install sqlalchemy sqlalchemy-migrate #     # Web  BuildBot-a pip install buildbot-www buildbot-grid-view buildbot-console-view buildbot-waterfall-view pip install python-dateutil #   web #         pip install buildbot-worker #Worker #  sudo pip install virtualenv #  

4. الخطوات الأولى

---

الوقت لإنشاء BuildMaster . سيكون لدينا في المجلد / الوطن / هابر / ماجستير .

 mkdir master buildbot create-master master #     

الخطوة التالية. إنشاء عامل . سيكون لدينا في المجلد / المنزل / هابر / العامل .

 mkdir worker buildbot-worker create-worker --umask=0o22 --keepalive=60 worker localhost:4000 yourWorkerName password 

عند بدء تشغيل Worker ، سيقوم بشكل افتراضي بإنشاء مجلد في / home / habr / worker باسم المشروع ، المحدد في master.cfg . وفي المجلد الذي يحمل اسم المشروع ، سيقوم بإنشاء دليل الإنشاء ، ثم يتم إجراء السحب فيه. سيكون دليل العمل للعمال هو الدليل / home / habr / yourProject / build .

المفتاح الذهبي
والآن بالنسبة لما كتبت الفقرة السابقة: لن يتم تنفيذ البرنامج النصي الذي سيطلب Master من العامل القيام به عن بعد في هذا الدليل ، لأن البرنامج النصي ليس لديه إذن بالتشغيل. لإصلاح الموقف ، تحتاج إلى مفتاح --umask = 0o22 ، الذي يفرض حظرًا على الكتابة إلى هذا الدليل ، لكنه يترك حقوق بدء التشغيل. ونحن بحاجة فقط هذا.

BuildMaster والعمال تأسيس اتصال بينهما. يحدث أن ينفجر وينتظر العامل استجابة من BuildMaster لبعض الوقت. في حالة عدم تلقي استجابة ، تتم إعادة الاتصال. المفتاح - keepalive = 60 هو ما تحتاجه للإشارة إلى الوقت الذي يتم بعده إعادة تمهيد الاتصال .

5. التكوين. خطوة خطوة صفة

---

يتم تكوين BuildMaster على جانب الجهاز ، حيث قمنا بتشغيل الأمر create-master . في حالتنا ، هذا هو الدليل / home / habr / master . لا يوجد ملف التكوين master.cfg بعد ، لكن الأمر نفسه أنشأ ملف master.cmg.sample بالفعل. تحتاج إلى إعادة تسميته في master.cfg.sample إلى master.cfg

 mv master.cfg.sample master.cfg 

دعنا نفتح هذا master.cfg . ونحن سوف نحلل ما يتكون منه. وبعد ذلك سنحاول إنشاء ملف التكوين الخاص بنا.

5.1 BuildmasterConfig

 c = BuildmasterConfig = {} 

BuildmasterConfig - القاموس الأساسي لملف التكوين. يجب أن تشارك في ملف التكوين. لسهولة الاستخدام ، يتم إدخال الاسم المستعار "c" في رمز التكوين. أسماء المفاتيح في c ["keyFromDist"] هي عناصر ثابتة للتفاعل مع BuildMaster . تحت كل مفتاح ، يتم استبدال الكائن المطابق كقيمة.

5.2 عمال

 c['workers'] = [worker.Worker("example-worker", "pass")] 

هذه المرة نشير إلى قائمة عمال البناء BuildMaster . أنشأنا Worker أعلاه من خلال تحديد اسم العامل وكلمة المرور . الآن يجب أن يتم تحديدها بدلاً من مثال العامل وتمريرها .

5.3 change_source

 c['change_source'] = [] c['change_source'].append(changes.GitPoller( 'git://github.com/buildbot/hello-world.git', workdir='gitpoller-workdir', branch='master', pollInterval=300)) 

باستخدام مفتاح change_source في القاموس c ، يمكننا الوصول إلى القائمة التي تريد أن تضع فيها الكائن الذي يستقصي المستودع برمز مصدر المشروع. يستخدم المثال مستودع Git ، والذي يتم استطلاعه في بعض الأوقات.

الوسيطة الأولى هي المسار إلى مستودعك.

workdir هو المسار إلى المجلد حيث على جانب Worker ، بالنسبة للمسار / home / habr / worker / yourProject / build ، ستخزن git النسخة المحلية من المستودع.

يحتوي الفرع على فرع محدد في المستودع يجب مراقبته.

يحتوي pollInterval على عدد الثواني التي سيتم بعدها استطلاع BuildMaster لمستودع التغييرات.

هناك عدة طرق لتتبع التغييرات في مستودع المشروع.

أسهل طريقة هي Polling ، مما يعني أن BuildMaster يقوم باستقصاء الخادم بشكل دوري مع المستودع. إذا كان الالتزام ينعكس التغييرات في المستودع ، فسيقوم BuildMaster مع بعض التأخير بإنشاء كائن تغيير داخلي وإرساله إلى معالج أحداث " المجدول" ، والذي سيبدأ الخطوات لإنشاء واختبار المشروع على العامل . من بين هذه الخطوات ، سيتم الإشارة إلى تحديث المستودع. على العامل ، سيتم إنشاء نسخة محلية من المستودع. سيتم الكشف عن تفاصيل هذه العملية أدناه في القسمين التاليين ( 5.4 و 5.5 ) .

طريقة أكثر أناقة لتتبع التغييرات في المستودع هي إرسال رسائل مباشرة من الخادم الذي يوجد عليه BuildMaster حول تغيير أكواد المصدر للمشروع. في هذه الحالة ، بمجرد قيام المطور بالتعهد ، سيرسل الخادم الذي يحتوي على مستودع المشروع رسالة إلى BuildMaster . وهذا بدوره ، سيتم اعتراضه عن طريق إنشاء كائن PBChangeSource . علاوة على ذلك ، سيتم نقل هذا الكائن إلى المجدول ، الذي ينشط خطوات تجميع المشروع واختباره. جزء مهم من هذه الطريقة يعمل مع البرامج النصية لربط الخادم في المستودع. في البرنامج النصي الخطاف المسؤول عن معالجة الإجراءات أثناء الالتزام ، تحتاج إلى استدعاء الأداة المساعدة sendchange وتحديد عنوان شبكة BuildMaster . يجب عليك تحديد منفذ الشبكة الذي سيستمع إلى PBChangeSource . PBChangeSource ، بالمناسبة ، جزء من BuildMaster . ستتطلب هذه الطريقة امتياز المشرف على الخادم حيث يوجد مستودع المشروع. تحتاج أولاً إلى إنشاء مستودع نسخ احتياطي.

5.4 shedulers

 c['schedulers'] = [] c['schedulers'].append(schedulers.SingleBranchScheduler( name="all", change_filter=util.ChangeFilter(branch='master'), treeStableTimer=None, builderNames=["runtests"])) c['schedulers'].append(schedulers.ForceScheduler( name="force", builderNames=["runtests"])) 

المجدولات هي عنصر يعمل كمشغل يقوم بتشغيل سلسلة التجميع والاختبار بأكملها للمشروع.


تم تحويل تلك التغييرات التي تم تسجيلها بواسطة change_source أثناء تشغيل BuildBot - a إلى كائن Change والآن يقوم كل Sheduler بناءً عليها بناءً على طلبات لبدء عملية إنشاء المشروع. ومع ذلك ، فإنه يحدد أيضًا وقت إرسال هذه الطلبات إلى قائمة الانتظار. موضوع يحتفظ Builder بقائمة انتظار طلب ويراقب حالة التجميع الحالي على Worker -e منفصل. منشئ موجود على كل من BuildMaster -e و Worke -e. يرسل بنية محددة من BuildMaster إلى Worker ، وهي سلسلة من الخطوات التي يجب اتباعها.
نرى أنه في المثال الحالي لمثل هذه الجداول ، يتم إنشاء قطعتين. علاوة على ذلك ، لكل منها نوعه الخاص.

SingleBranchScheduler هي واحدة من فصول الجدول الأكثر شعبية. تراقب فرع واحد ويتم تشغيله بواسطة تغيير مسجل فيه. عندما يرى التغييرات ، يمكنه تأجيل إرسال طلب للبناء (تأجيل الفترة المحددة في treeStableTimer المعلمة الخاصة). يحدد الاسم اسم الجدول الذي سيتم عرضه في واجهة BuildBot -web . يتم تعيين عامل تصفية في ChangeFilter ، بعد تمرير التغييرات في الفرع تطالب بالجدول لإرسال طلب بناء. تم تحديد اسم البناء - a في اسم البناء ، والذي سنقوم بتحديده لاحقًا. الاسم في حالتنا سيكون هو نفسه اسم المشروع: yourProject .

ForceScheduler هو شيء بسيط جدا. يتم تشغيل هذا النوع من الجداول بنقرة بالماوس من خلال واجهة BuildBot -web . المعلمات لها نفس الجوهر كما في SingleBranchScheduler .

PS رقم 3. فجأة تأتي في متناول اليدين
الدوري هو جدول يتم تشغيله بتردد محدد زمنياً. يبدو وكأنه دعوة مثل هذا

 from buildbot.plugins import schedulers nightly = schedulers.Periodic(name="daily", builderNames=["full-solaris"], periodicBuildTimer=24*60*60) c['schedulers'] = [nightly] 

5.5 BuildFactory

 factory = util.BuildFactory() factory.addStep(steps.Git(repourl='git://github.com/buildbot/hello-world.git', mode='incremental')) factory.addStep(steps.ShellCommand(command=["trial", "hello"], env={"PYTHONPATH": "."})) 

periodBuildTimer يحدد وقت هذه الدورية بالثواني.

ينشئ BuildFactory بنية ملموسة ، ثم يرسلها المنشئ إلى العامل . يشير BuildFactory إلى الخطوات التي يجب على العامل اتباعها. تتم إضافة الخطوات عن طريق استدعاء الأسلوب addStep.


الخطوة الأولى المضافة في هذا المثال هي git clean -d -f -f –x ، ثم git checkout . يتم تضمين هذه الإجراءات في معلمة الطريقة ، والتي لا تتم الإشارة إليها بوضوح ، ولكنها تتضمن القيمة الافتراضية للحديث . تشير المعلمة mode = 'incremental' إلى أن الملفات الموجودة في الدليل حيث يتم إجراء chechout ، بينما مفقودة من المستودع ، تظل دون تغيير.

الخطوة الثانية المضافة هي استدعاء البرنامج النصي التجريبي باستخدام المعلمة hello على الجانب Worker من الدليل / home / habr / worker / yourProject / build مع متغير البيئة PATHONPATH = ... حتى تتمكن من كتابة البرامج النصية الخاصة بك وتنفيذها على Worker side -a من خلال use.ShellCommand الخطوة. هذه النصوص يمكن وضعها مباشرة في المستودع. بعد ذلك ، سوف يذهبوا إلى المنزل / المنزل / habr / العامل / yourproject / build . ومع ذلك ، هناك نوعان من "buts":

1. يجب إنشاء العامل باستخدام مفتاح التبديل --umask بحيث لا يمنع حقوق التنفيذ بعد تسجيل الخروج .
2. عندما تضغط git على هذه البرامج النصية ، من الضروري تحديد الخاصية exacutable ، بحيث لا تفقد Git من خلال chechout -e الحق في تنفيذ البرنامج النصي.

5.6 بناة

 c['builders'] = [] c['builders'].append(util.BuilderConfig(name="runtests", workernames=["example-worker"], factory=factory)) 

حول ما تم وصفه منشئ هنا . الآن سأتحدث بمزيد من التفاصيل حول كيفية إنشائه. BuilderConfig هو بناء المنشئ . يمكنك تحديد العديد من هذه المنشئات في c ['builders'] ، نظرًا لأن هذه قائمة كائنات نوع البناء . سنقوم الآن بإعادة كتابة المثال قليلاً من BuildBot ، مما يجعله أقرب إلى مهمتنا.

 c['builders'] = [] c['builders'].append(util.BuilderConfig(name="yourProject", workernames=["yourWorkerName"], factory=factory)) 

الآن سأقول عن المعلمات BuilderConfig .

اسم يحدد اسم باني -A. هنا أطلقنا عليها اسمك . هذا يعني أنه على العامل ، سيتم إنشاء هذا المسار / home / habr / worker / yourProject / build . يبحث Sheduler عن باني بهذا الاسم.

أسماء العمل تحتوي على قائمة العمال . يجب إضافة كل منها إلى [العمال] .

المصنع هو البناء المحدد الذي يرتبط به الباني . سوف يرسل كائن بناء إلى Worker لإكمال كافة الخطوات التي تشكل هذا البناء -a.

6. مثال التكوين الخاصة

---

فيما يلي بنية مشروع نموذج أقترح تنفيذه من خلال BuildBot
.

سوف نستخدم svn كنظام للتحكم في الإصدار. سيكون المستودع نفسه في سحابة معينة. هنا هو عنوان هذه السحابة svn.host/svn/yourProject/trunk . في السحابة تحت svn هناك اسم مستخدم: مستخدم ، passwd: حساب كلمة المرور . البرامج النصية التي هي خطوات build -a ستقع أيضًا في فرع svn ، في مجلد buildbot / worker_linux منفصل. توجد هذه البرامج النصية في المستودع مع حفظ الخاصية القابلة للتنفيذ .

يعمل BuildMaster و Worker على نفس المضيف project.host . يخزن BuildMaster ملفاته في المجلد / home / habr / master . يخزن العامل المسار التالي / المنزل / habr / العامل . يتم إجراء الاتصال بين عمليتي BuildMaster و Worker من خلال منفذ 4000 باستخدام بروتوكول BuildBot- a ، أي بروتوكول 'pb' .

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

سنقوم بتوصيل تعيين الويب BuildBot إلى المنفذ 80 لـ project.host . Apatch هو اختياري. تحتوي المكتبة الملتوية بالفعل على خادم ويب ، ويستخدمه BuildBot .

سوف نستخدم sqlite لتخزين المعلومات الداخلية لـ BuildBot .

بالنسبة للبريد ، فأنت بحاجة إلى المضيف smtp.your.domain - فهو يتيح إرسال رسائل بريد إلكتروني من projectHost@your.domain دون مصادقة. أيضا على المضيف " بروتوكول نقل البريد الإلكتروني " بروتوكول يتم الاستماع إلى في 1025.

هناك شخصان مشتركان في العملية: المسؤول والمستخدم . المشرف يدير BuildBot . المستخدم هو الشخص الذي ارتكب الالتزام .

يتم إنشاء ملف exacutable من خلال pyinstaller . يتم إنشاء الوثائق من خلال doxygen .

بالنسبة لهذا الهيكل ، كتبت هذا master.cfg :


تحتاج أولاً إلى إنشاء BuildMaster و Worker -a. ثم الصق ملف master.cfg هذا في / home / habr / master .

الخطوة التالية هي بدء تشغيل خدمة BuildMaster

 sudo buildbot start /home/habr/master 

ثم ابدأ تشغيل خدمة العامل

 buildbot-worker start /home/habr/worker 

القيام به! الآن ستقوم Buildbot بتتبع التغييرات وتنفيذها على الالتزام في svn ، باتباع خطوات بناء واختبار المشروع باستخدام البنية أعلاه.

أدناه سوف أصف بعض ميزات master.cfg أعلاه .

6.1 في الطريق إلى master.cfg الخاص بك

أثناء كتابة master.cfg ، سيتم ارتكاب الكثير من الأخطاء ، لذلك ستحتاج إلى قراءة ملف السجل. يتم تخزينه على كل من المسار المطلق لـ BuildMaster -ec /home/habr/master/twistd.log وجانب Worker -a مع المسار المطلق / home/habr/worker/twistd.log . عند قراءة الخطأ وإصلاحه ، ستحتاج إلى إعادة تشغيل خدمة BuildMaster -a. إليك كيفية القيام بذلك:

 sudo buildbot stop /home/habr/master sudo buildbot upgrade-master /home/habr/master sudo buildbot start /home/habr/master 

6.2 العمل مع svn

 svn_poller = changes.SVNPoller(repourl="https://svn.host/svn/yourProject/trunk", svnuser="user", svnpasswd="password", pollinterval=60, split_file=util.svn.split_file_alwaystrunk ) c['change_source'] = svn_poller hourlyscheduler = schedulers.SingleBranchScheduler( name="your-project-schedulers", change_filter=util.ChangeFilter(branch=None), builderNames=["yourProject"], properties = {'owner': 'admin'} ) c['schedulers'] = [hourlyscheduler] checkout = steps.SVN(repourl='https://svn.host/svn/yourProject/trunk', mode='full', method='fresh', username="user", password="password", haltOnFailure=True) 

أولاً ، ألقِ نظرة على svn_poller . هذه هي الواجهة نفسها التي تستطلع بانتظام المستودع مرة واحدة في الدقيقة. في هذه الحالة ، يصل svn_poller فقط إلى فرع الصندوق . تقوم المعلمة الغامضة split_file = util.svn.split_file_alwaystrunk بتعيين القواعد: كيفية تقسيم بنية مجلدات svn إلى فروع. يقدم لهم طرقا نسبية. بدوره ، يقوم split_file_alwaystrunk بتبسيط العملية بالقول إن الصندوق الرئيسي فقط هو في المستودع.

في " المجدولون" ، يتم تحديد ChangeFilter ، والذي لا يرى أي شيء ويربط فرع الصندوق معه وفقًا للاقتران المحدد من خلال split_file_alwaystrunk . استجابة للتغيرات في الجذع ، يبدأ المنشئ المسمى yourProject .

هناك حاجة إلى خصائص هنا حتى يتلقى المسؤول النشرة الإخبارية من التجميع ونتائج الاختبار كمالك لهذه العملية.

تكون خطوة check- a checkout قادرة على حذف أي ملفات موجودة في الإصدار المحلي من مستودع Worker بالكامل. ثم القيام التحديث svn الكامل. يتم تكوين الوضع من خلال وضع المعلمة = كامل ، طريقة = جديدة . تشير المعلمة haltOnTailure إلى أنه في حالة عدم نجاح تحديث svn ، فيجب تعليق عملية التجميع والاختبار بأكملها ، نظرًا لأن الخطوات الإضافية لا معنى لها.

6.3 خطاب لك: يحق للمراسلين التصريح

للصحفيين هي خدمة إعلام البريد.

 template_html=u'''\ <h4>  : {{ summary }}</h4> <p>   : {{ workername }}</p> <p>: {{ projects }}</p> <p>         : {{ buildbot_url }}</p> <p>         : {{ build_url }}</p> <p> WinSCP     c ip:xxx.xx.xxx.xx.   habr/password,   executable    ~/worker/yourProject/build/dist.</p> <p><b>    Buildbot</b></p> ''' sendMessageToAll = reporters.MailNotifier(fromaddr="projectHost@your.domain", sendToInterestedUsers=True, lookup="your.domain", relayhost="smtp.your.domain", smtpPort=1025, mode="warnings", extraRecipients=['user@your.domain'], messageFormatter=reporters.MessageFormatter( template=template_html, template_type='html', wantProperties=True, wantSteps=True) ) c['services'] = [sendMessageToAll] 

يمكنه إرسال الرسائل بعدة طرق .

يستخدم MailNotifier البريد لإرسال الإشعارات.

template_html يعين قالب النص للنشرة الإخبارية. لإنشاء العلامات ، استخدم html. يتم تعديله بواسطة محرك jinja2 (يمكن مقارنته مع django ). يحتوي BuildBot على مجموعة من المتغيرات ، يتم استبدال قيمها بالقالب في عملية تكوين نص الرسالة. يتم إدراج هذه المتغيرات في {{double curly braces}}. لذلك ، على سبيل المثال ، يعرض الملخص حالة العمليات المكتملة ، أي النجاح أو الفشل. والمشاريع ستخرج مشروعك . لذلك ، باستخدام أوامر التحكم في jinja2 ومتغيرات BuildBot وتنسيقات سلسلة python ، يمكنك إنشاء رسالة مفيدة للغاية.

MailNotifier يحتوي على الوسائط التالية.

فرومدر - العنوان الذي سيتلقى منه الجميع النشرة الإخبارية.

sendToInterestedUsers = True يرسل رسالة إلى المالك والمستخدم الذي قام بالالتزام .

بحث - لاحقة تضاف إلى أسماء المستخدمين الذين يتلقون النشرة الإخبارية. إذن المشرف كمستخدم سوف يتلقى النشرة الإخبارية على admin@your.domain.

يحدد relayhost اسم المضيف الذي يفتح عليه خادم smtp ، ويحدد smptPort رقم المنفذ الذي يستمع إليه خادم smtp .

يشير الوضع = "تحذير" إلى أنه يجب إجراء المراسلات فقط إذا كانت هناك خطوة بناء واحدة على الأقل انتهت بفشل أو حالة تحذير. في حالة النجاح ، لا يكون البريد مطلوبًا. يحتوي

ExtraRecipients على قائمة بالأفراد الذين يجب أن يتم إرسال البريد لهم بالإضافة إلى المالك والشخص الذي قام بالالتزام .

messageFormatter هو كائن يحدد تنسيق الرسالة ، القالب ، ومجموعة المتغيرات المتاحة من jinja2 . معلمات مثل wantProperties = True و wantSteps = True حدد هذه المجموعة من المتغيرات المتاحة.

مع ['services'] = [sendMessageToAll] توفر قائمة من الخدمات ، من بينها خدماتنامراسل .

لقد فعلنا ذلك! مبروك

---

لقد أنشأنا التكوين الخاص بنا وشاهدنا الوظائف التي يمكن لـ BuildBot القيام بها . أعتقد أن هذا يكفي لفهم ما إذا كانت هذه الأداة ضرورية لإنشاء مشروعك. هل هو مثير لك؟ هل سيكون في متناول اليد بالنسبة لك؟ هل هي مريحة للعمل مع؟ ثم أكتب هذا المقال لسبب وجيه.

وأكثر شيء واحد.أود أن أرى المجتمع المحترف الذي يستخدم BuildBot يتوسع ، وترجمت الأدلة ، وهناك المزيد من الأمثلة.

شكرا لكم جميعا على اهتمامكم. حظا سعيدا