Contoh Implementasi Integrasi Berkelanjutan Menggunakan BuildBot

(Gambar oleh Computerizer dari Pixabay)

Hai

Nama saya Evgeny Cherkin , saya programmer dari tim pengembangan di perusahaan pertambangan Polymetal .

Saat memulai proyek besar, Anda mulai berpikir: "Perangkat lunak apa yang lebih baik untuk digunakan untuk pemeliharaannya?". Sebuah proyek TI sebelum rilis versi berikutnya melewati serangkaian tahapan. Ada baiknya ketika rantai langkah-langkah ini diotomatisasi. Proses otomatis untuk merilis versi baru proyek TI disebut Integrasi Berkelanjutan . BuildBot ternyata menjadi penolong yang baik bagi kami, menerapkan proses ini.

Pada artikel ini, saya memutuskan untuk memberikan gambaran umum tentang fitur-fitur BuildBot . Apa yang mampu dilakukan oleh perangkat lunak ini? Bagaimana cara mendekatinya dan bagaimana membangun HUBUNGAN KERJA EFEKTIF yang normal dengannya? Anda juga dapat menerapkan pengalaman kami kepada diri sendiri dengan membuat pada mesin Anda layanan yang berfungsi untuk merakit dan menguji proyek Anda.

1. Mengapa BuildBot?

---

Sebelumnya di habr-e, saya menemukan artikel tentang penerapan Integrasi Berkelanjutan menggunakan BuildBot . Misalnya, yang ini bagi saya paling informatif. Ada contoh lain - lebih sederhana . Artikel-artikel ini dapat dibumbui dengan contoh dari manual , dan ini setelahnya, dalam bahasa Inggris. Coupe adalah titik awal yang baik. Setelah membaca artikel ini, Anda mungkin ingin segera melakukan sesuatu di BuildBot .

Hentikan itu! Apakah ada yang bahkan menggunakannya dalam proyek mereka? Ternyata ya, banyak yang sudah menerapkannya dalam tugasnya. Anda dapat menemukan contoh penggunaan BuildBot di arsip kode Google.

Jadi apa logika orang menggunakan buildbot ? Lagi pula, ada alat lain: CruiseControl dan Jenkins . Saya akan menjawab seperti ini. Untuk sebagian besar tugas, Jenkins akan cukup. BuildBot , pada gilirannya, lebih adaptif, dan tugas-tugas di sana diselesaikan semudah di Jenkins . Pilih kamu Tetapi karena kami mencari alat untuk proyek target yang sedang berkembang, mengapa tidak memilih yang memungkinkan kami, mulai dari langkah-langkah sederhana, untuk mendapatkan sistem pembangunan yang memiliki interaktivitas dan antarmuka yang unik.

Bagi mereka yang target proyeknya ditulis dengan python, muncul pertanyaan: "Mengapa tidak memilih sistem integrasi yang memiliki antarmuka yang jelas dalam hal bahasa yang digunakan dalam proyek?". Dan sekarang saatnya untuk memperkenalkan manfaat BuildBot .

Jadi, "kuartet instrumental" kami. Bagi saya sendiri, saya mendefinisikan empat fitur BuildBot :

1. Ini adalah kerangka kerja open source di bawah GPL
2. Ini menggunakan python sebagai alat konfigurasi dan menjelaskan tindakan yang diperlukan.
3. Ini adalah peluang untuk menerima respons dari mesin tempat perakitan berlangsung.
4. Ini akhirnya persyaratan minimum untuk Host. Penyebaran membutuhkan python dan twisted, dan tidak ada mesin virtual atau mesin java yang diperlukan.

2. Konsep yang dipimpin oleh BuildMaster

---

Pusat arsitektur distribusi tugas adalah BuildMaster . Ini adalah layanan yang:

• melacak perubahan di pohon sumber proyek
• mengirimkan perintah yang harus dijalankan oleh layanan Pekerja untuk membangun proyek dan mengujinya
• memberi tahu pengguna tentang hasil tindakan yang diambil

BuildMaster dikonfigurasi melalui file master.cfg . File ini adalah akar dari BuildMaster . Nanti saya akan menunjukkan bagaimana root ini dibuat. File master.cfg itu sendiri mengandung python, skrip yang menggunakan panggilan BuildBot .

BuildBot paling penting berikutnya disebut Worker . Layanan ini dapat dijalankan pada host yang berbeda dengan OS yang berbeda, atau mungkin di tempat BuildMaster berada . Itu juga dapat ada di lingkungan virtual yang disiapkan khusus dengan paket dan variabel sendiri. Lingkungan virtual ini dapat disiapkan menggunakan utilitas python seperti vertualenv, venv .

BuildMaster menyiarkan perintah kepada setiap Worker , yang, pada gilirannya, mengeksekusi mereka. Artinya, ternyata proses membangun dan menguji proyek dapat pergi ke Pekerja di Windows dan Pekerja lain di linux.

Proses checkout kode sumber proyek terjadi pada setiap Pekerja .

3. Instalasi

---

Jadi ayo pergi. Saya akan menggunakan Ubuntu 18.04 sebagai tuan rumah. Di atasnya saya akan menempatkan satu BuildMaster -a dan satu Pekerja -a. Tetapi pertama-tama Anda harus menginstal python3.7:

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

Bagi mereka yang membutuhkan python3.7.2 bukannya 3.7.1, Anda dapat melakukan hal berikut:

 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 

Langkah selanjutnya adalah menginstal Twited dan BuildBot , serta paket yang mengaktifkan fungsionalitas BuildBot -a tambahan.

 /*   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. Langkah pertama

---

Saatnya membuat BuildMaster . Kami akan memilikinya di folder / home / habr / master .

 mkdir master buildbot create-master master #     

Langkah selanjutnya. Buat Pekerja . Kami akan memilikinya di folder / home / habr / pekerja .

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

Ketika Anda memulai Worker , secara default ia akan membuat folder di / home / habr / pekerja dengan nama proyek, yang ditentukan dalam master.cfg . Dan dalam folder dengan nama proyek, ia akan membuat direktori build , dan kemudian checkout akan dilakukan di dalamnya. Direktori kerja untuk Pekerja adalah direktori / home / habr / yourProject / build .

Kunci Emas
Dan sekarang untuk apa yang saya tulis paragraf sebelumnya: skrip yang Master akan minta Pekerja untuk melakukan jarak jauh di direktori ini tidak akan dieksekusi, karena skrip tidak memiliki izin untuk dijalankan. Untuk memperbaiki situasi, Anda perlu kunci --umask = 0o22 , yang memberlakukan larangan menulis ke direktori ini, tetapi meninggalkan hak startup. Dan kita hanya butuh ini.

BuildMaster dan Worker membangun koneksi di antara mereka. Kebetulan itu terputus dan Pekerja menunggu respons dari BuildMaster untuk beberapa waktu. Jika tidak ada respons yang diterima, koneksi dimulai ulang. Kunci --keepalive = 60 adalah apa yang Anda butuhkan untuk menunjukkan waktu setelah itu menghubungkan reboot.

5. Konfigurasi. Resep langkah demi langkah

---

Konfigurasi BuildMaster dilakukan di sisi mesin, tempat kami menjalankan perintah create-master . Dalam kasus kami, ini adalah direktori / home / habr / master . File konfigurasi master.cfg belum ada, tetapi perintah itu sendiri telah membuat file master.cmg.sample . Anda harus mengganti nama di master.cfg.sample ke master.cfg

 mv master.cfg.sample master.cfg 

Mari kita buka master.cfg ini. Dan kami akan menganalisis dari apa itu. Dan setelah itu kami akan mencoba membuat file konfigurasi kami sendiri.

5.1 BuildmasterConfig

 c = BuildmasterConfig = {} 

BuildmasterConfig - kamus dasar file konfigurasi. Itu harus terlibat dalam file konfigurasi. Untuk kemudahan penggunaan, alias "c" dimasukkan dalam kode konfigurasi. Nama-nama kunci dalam c ["keyFromDist"] adalah elemen tetap untuk berinteraksi dengan BuildMaster . Di bawah setiap kunci, objek terkait diganti sebagai nilai.

5.2 pekerja

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

Kali ini kami menunjukkan daftar Pekerja BuildMaster . Kami menciptakan Pekerja di atas dengan menetapkan nama-pekerja Anda dan kata sandi . Sekarang mereka harus ditentukan, bukan contoh-pekerja dan lulus .

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)) 

Menggunakan kunci change_source dari kamus c , kami mendapatkan akses ke daftar di mana Anda ingin meletakkan objek yang polling repositori dengan kode sumber proyek. Contoh ini menggunakan repositori Git, yang disurvei pada beberapa periode tertentu.

Argumen pertama adalah jalur ke repositori Anda.

workdir adalah path ke folder di mana di sisi Worker , relatif terhadap path / home / habr / pekerja / proyek Anda / build, git akan menyimpan repositori versi lokal.

cabang berisi cabang tertentu di repositori yang harus dipantau.

pollInterval berisi jumlah detik setelah BuildMaster akan melakukan polling repositori untuk perubahan.

Ada beberapa metode untuk melacak perubahan di repositori proyek.

Metode termudah adalah Polling , yang menyiratkan bahwa BuildMaster secara berkala polling server dengan repositori. Jika komit mencerminkan perubahan dalam repositori, maka BuildMaster dengan beberapa penundaan akan membuat objek perubahan internal dan mengirimkannya ke pengendali event Penjadwal , yang akan memulai langkah-langkah untuk membangun dan menguji proyek pada Pekerja . Di antara langkah-langkah ini, pembaruan repositori akan ditunjukkan. Di Worker salinan lokal dari repositori akan dibuat. Rincian proses ini akan diungkapkan di bawah dalam dua bagian berikutnya ( 5.4 dan 5.5 ) .

Metode pelacakan perubahan dalam repositori yang lebih elegan adalah dengan mengirim pesan langsung dari server tempat ia berada di BuildMaster tentang cara mengubah kode sumber proyek. Dalam hal ini, segera setelah pengembang membuat komit , server dengan repositori proyek akan mengirim pesan ke BuildMaster . Dan itu, pada gilirannya, akan dicegat dengan membuat objek PBChangeSource . Selanjutnya, objek ini akan ditransfer ke Penjadwal , yang mengaktifkan langkah-langkah untuk perakitan proyek dan pengujiannya. Bagian penting dari metode ini adalah bekerja dengan skrip kait server dalam repositori. Di skrip kait yang bertanggung jawab untuk menangani tindakan selama komit , Anda perlu memanggil utilitas sendchange dan menentukan alamat jaringan BuildMaster . Anda harus menentukan port jaringan yang akan mendengarkan PBChangeSource . Omong -omong, PBChangeSource adalah bagian dari BuildMaster . Metode ini akan memerlukan admin- hak istimewa di server tempat repositori proyek berada. Pertama, Anda perlu membuat repositori cadangan.

5.4 penjadwal

 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"])) 

penjadwal adalah elemen yang bertindak sebagai pemicu yang menjalankan seluruh rantai perakitan dan pengujian proyek.


Perubahan-perubahan yang dicatat oleh change_source dikonversi selama operasi BuildBot -a menjadi objek Ubah dan sekarang setiap Sheduler berdasarkan pada mereka membangun permintaan untuk memulai proses membangun proyek. Namun, itu juga menentukan kapan harus mengirim permintaan ini ke antrian. Obyek Builder membuat antrian permintaan dan memonitor status perakitan saat ini di Worker -e yang terpisah. Builder ada di BuildMaster -e dan Worker -e. Dia mengirimkan build spesifik dari BuildMaster ke Worker , serangkaian langkah yang harus diikuti.
Kita melihat bahwa dalam contoh saat ini dari penjadwal tersebut , 2 buah dibuat. Apalagi masing-masing memiliki tipe sendiri.

SingleBranchScheduler adalah salah satu kelas jadwal paling populer. Ini memantau satu cabang dan dipicu oleh perubahan yang tercatat di dalamnya. Ketika dia melihat perubahan, dia dapat menunda mengirim permintaan untuk konstruksi (menunda untuk periode yang ditentukan dalam treeStableTimer parameter khusus). Nama menentukan nama jadwal yang akan ditampilkan di antarmuka BuildBot -web . Filter diatur dalam ChangeFilter , setelah melewati perubahan di cabang yang meminta jadwal untuk mengirim permintaan build. Nama builder -a ditentukan dalam builderNames , yang akan kita tentukan sedikit kemudian. Nama dalam kasus kami akan sama dengan nama proyek: proyek Anda.

ForceScheduler adalah hal yang sangat sederhana. Jenis jadwal ini dipicu oleh klik mouse melalui antarmuka BuildBot -web . Parameter memiliki esensi yang sama seperti di SingleBranchScheduler .

PS No. 3. Tiba-tiba berguna
Periodik adalah jadwal yang dipicu pada frekuensi waktu-tetap tertentu. Sepertinya panggilan seperti ini

 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": "."})) 

periodicBuildTimer menetapkan waktu periodisitas ini dalam detik.

BuildFactory menciptakan bangunan beton, yang kemudian dikirim oleh tukang ke Pekerja . BuildFactory menunjukkan langkah-langkah yang harus diikuti oleh Pekerja . Langkah-langkah ditambahkan dengan memanggil metode addStep.


Langkah pertama yang ditambahkan dalam contoh ini adalah git clean -d -f -f –x , lalu git checkout . Tindakan ini tertanam dalam parameter metode , yang tidak ditunjukkan dengan jelas, tetapi menyiratkan nilai default segar . Parameter mode = 'incremental' menunjukkan bahwa file-file dari direktori tempat chechout dilakukan, walaupun hilang dari repositori, tetap tidak tersentuh.

Langkah kedua yang ditambahkan adalah memanggil skrip percobaan dengan parameter halo di sisi Pekerja dari direktori / home / habr / pekerja / proyek Anda / build dengan variabel lingkungan PATHONPATH = ... Jadi Anda dapat menulis skrip Anda sendiri dan menjalankannya di sisi Pekerja -a melalui langkah util.ShellCommand . Script ini dapat dimasukkan langsung ke dalam repositori. Kemudian selama chechout mereka akan pergi ke / home / habr / pekerja / Proyek Anda / membangun . Namun, kemudian ada dua "tapi":

1. Pekerja harus dibuat dengan saklar --umask sehingga tidak memblokir hak eksekusi setelah checkout -a.
2. Ketika git mendorong skrip-skrip ini, perlu untuk menentukan properti exacutable , sehingga dengan chechout -e Git tidak kehilangan hak untuk mengeksekusi skrip.

5.6 pembangun

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

Tentang apa yang dijelaskan Builder di sini . Sekarang saya akan berbicara lebih detail tentang cara membuatnya. BuilderConfig adalah pembangun konstruktor. Anda dapat menentukan beberapa konstruktor tersebut di c ['builders'] , karena ini adalah daftar objek tipe builder . Sekarang kita akan sedikit menulis ulang contoh dari BuildBot , membawanya lebih dekat ke tugas kita.

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

Sekarang saya akan memberi tahu tentang parameter BuilderConfig .

name menetapkan pembangun nama -a. Di sini kami menyebutnya Proyek Anda . Ini berarti bahwa pada Pekerja ini jalan / rumah / habr / pekerja / Proyek Anda / akan dibuat. Sheduler mencari pembangun dengan nama itu.

nama pengerjaan berisi daftar Pekerja . Masing-masing harus ditambahkan ke c ['pekerja'] .

factory adalah build spesifik yang terkait dengan builder . Ini akan mengirimkan objek build ke Worker untuk menyelesaikan semua langkah yang membentuk build -a ini.

6. Contoh konfigurasi sendiri

---

Berikut adalah contoh arsitektur proyek yang saya usulkan untuk diimplementasikan melalui BuildBot
.

Kami akan menggunakan svn sebagai sistem kontrol versi. Repositori itu sendiri akan berada di cloud tertentu. Berikut adalah alamat cloud svn.host/svn/yourProject/trunk ini . Di cloud di bawah svn ada nama pengguna: pengguna , passwd: akun kata sandi . Skrip yang merupakan langkah build -a juga akan terletak di cabang svn , di folder buildbot / worker_linux yang terpisah. Skrip ini berada di repositori dengan properti yang dapat dieksekusi disimpan.

BuildMaster dan Worker bekerja pada host project.host yang sama. BuildMaster menyimpan file-nya di folder / home / habr / master . Pekerja menyimpan jalur / rumah / habr / pekerja berikut . Komunikasi antara proses BuildMaster dan Pekerja dilakukan melalui 4000 port menggunakan protokol BuildBot -a, yaitu protokol 'pb' .

Proyek target sepenuhnya ditulis dalam python. Tugasnya adalah melacak perubahannya, membuat file yang dapat dieksekusi, menghasilkan dokumentasi, melakukan pengujian. Jika terjadi kegagalan, semua pengembang perlu mengirim pesan ke email bahwa ada tindakan yang gagal.

Kami akan menghubungkan pemetaan web BuildBot ke port 80 untuk project.host . Pengiriman adalah opsional. Perpustakaan bengkok sudah memiliki server web, BuildBot menggunakannya.

Kami akan menggunakan sqlite untuk menyimpan informasi internal untuk BuildBot .

Untuk mengirim surat, Anda memerlukan host smtp.your.domain - memungkinkan pengiriman email dari projectHost@your.domain tanpa autentikasi. Juga pada ' smtp ' host protokol didengarkan pada 1025.

Ada dua orang yang terlibat dalam proses: admin dan pengguna . admin mengelola BuildBot . pengguna adalah orang yang melakukan komit .

File exacutable dihasilkan melalui pyinstaller . Dokumentasi dihasilkan melalui oksigen .

Untuk arsitektur ini, saya menulis master.cfg ini:


Pertama, Anda perlu membuat BuildMaster dan Worker -a. Kemudian tempelkan file master.cfg ini ke / home / habr / master .

Langkah selanjutnya adalah memulai layanan BuildMaster

 sudo buildbot start /home/habr/master 

Kemudian mulai pekerja- layanan

 buildbot-worker start /home/habr/worker 

Selesai! Sekarang Buildbot akan melacak perubahan dan menjalankan komit di svn , mengikuti langkah-langkah membangun dan menguji proyek dengan arsitektur di atas.

Di bawah ini saya akan menjelaskan beberapa fitur dari master.cfg di atas .

6.1 Dalam perjalanan ke master.cfg Anda

Saat menulis master.cfg Anda , banyak kesalahan akan terjadi, jadi Anda harus membaca file log. Ini disimpan di kedua path absolut BuildMaster -home / home/ habr/ master/ twistd.log dan Pekerja- sisi dengan jalur absolut /home/habr/worker/twistd.log . Ketika Anda membaca kesalahan dan memperbaikinya, Anda harus me-restart layanan BuildMaster -a. Inilah cara melakukannya:

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

6.2 Bekerja dengan 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) 

Pertama, lihat svn_poller . Ini adalah antarmuka yang sama yang secara teratur polling repositori satu menit sekali. Dalam hal ini, svn_poller hanya mengakses cabang trunk . Parameter misterius split_file = util.svn.split_file_alwaystrunk menetapkan aturan: cara membagi struktur folder svn menjadi cabang. Dia menawarkan mereka cara yang relatif. Pada gilirannya, split_file_alwaystrunk menyederhanakan proses dengan mengatakan bahwa hanya trunk yang ada di repositori.

Di Penjadwal , ChangeFilter ditentukan , yang melihat Tidak Ada dan mengaitkan cabang trunk dengannya sesuai dengan asosiasi yang ditentukan melalui split_file_alwaystrunk . Menanggapi perubahan di bagasi , itu mulai pembangun bernama Proyek Anda .

properti di sini diperlukan sehingga admin menerima buletin dari majelis dan hasil pengujian sebagai pemilik proses.

Langkah checkout build -a dapat menghapus semua file yang ada di versi lokal dari repositori Worker . Kemudian lakukan pembaruan penuh svn . Mode ini dikonfigurasi melalui mode parameter = penuh , metode = segar . Parameter haltOnTailure menunjukkan bahwa jika pembaruan svn tidak berhasil , maka seluruh proses perakitan dan pengujian harus ditangguhkan, karena langkah-langkah selanjutnya tidak masuk akal.

6.3 Surat kepada Anda: wartawan berwenang untuk menyatakan

wartawan adalah layanan notifikasi surat.

 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] 

Itu dapat mengirim pesan dengan banyak cara .

MailNotifier menggunakan email untuk mengirim notifikasi.

template_html menetapkan template teks untuk buletin. Untuk membuat markup, gunakan html. Ini dimodifikasi oleh mesin jinja2 (dapat dibandingkan dengan Django ). BuildBot memiliki serangkaian variabel, yang nilainya disubstitusi ke dalam templat dalam proses pembentukan teks pesan. Variabel-variabel ini tertulis dalam {{double curly braces}}. Jadi, misalnya, ringkasan menampilkan status operasi yang diselesaikan, mis. Sukses atau gagal. Dan proyek akan menampilkan Proyek Anda . Jadi, menggunakan perintah kontrol di jinja2 , variabel BuildBot , dan pemformat string python, Anda bisa membuat pesan yang sangat informatif.

MailNotifier berisi argumen berikut.

fromaddr - alamat dari mana setiap orang akan menerima buletin.

sendToInterestedUsers = Benar mengirim pesan kepada pemilik dan pengguna yang membuat komit .

lookup - suffix yang akan ditambahkan ke nama-nama pengguna yang menerima buletin. Jadi admin sebagai pengguna akan menerima buletin di admin@your.domain.

relayhost menentukan nama host di mana server smtp terbuka, dan smptPort menentukan nomor port yang didengarkan oleh server smtp .

mode = "warning" mengatakan bahwa pengiriman surat hanya boleh dilakukan jika setidaknya ada satu langkah pembangunan yang diakhiri dengan status kegagalan atau peringatan. Jika berhasil, pengiriman surat tidak diperlukan.

extraRecipient berisi daftar individu yang harus dikirimi surat kepada pemilik dan orang yang membuat komit .

messageFormatter adalah objek yang mendefinisikan format pesan, templatnya, dan sekumpulan variabel yang tersedia dari jinja2 . Parameter seperti wantProperties = True dan wantSteps = True menentukan set variabel yang tersedia ini.

dengan ['layanan'] = [sendMessageToAll] menyediakan daftar layanan, di antaranya adalah milik kamireporter .

Kami berhasil! Selamat saya

---

Kami membuat konfigurasi kami sendiri dan melihat fungsionalitas yang mampu dibangun oleh BuildBot . Ini, saya pikir, cukup untuk memahami apakah alat ini diperlukan untuk membuat proyek Anda. Apakah dia menarik bagi Anda? Akankah ini berguna bagi Anda? Apakah nyaman untuk bekerja dengannya? Lalu saya menulis artikel ini untuk alasan yang bagus.

Dan satu hal lagi.Saya ingin komunitas profesional menggunakan BuildBot untuk menjadi lebih luas, manual diterjemahkan, dan lebih banyak contoh.

Terima kasih atas perhatiannya. Semoga beruntung