Тонке налаштування Buildbot’а

Сьогодні ми продовжимо налаштування Buildbot’а. Сподіваюсь, читач вже знайомий з попереднім матеріалом на дану тему, тому тут будуть вказані типові запитання, вдосконалення, можливі проблеми без зайвих слів.

Додання нового клієнта

Насправді, додати нового клієнта не так вже й складно. Для цього необхідно

  1. Додати логін і пароль бота до параметру buildslaves
  2. Прив’язати до процесу збирання
  3. Внести в розклад збирання

Слід не забути одну просту річ: якщо доступ до репозитарію віддалений, необхідно хоча б раз виконати вхід до
віддаленої системи вручну. Якщо цього не зробити, бот не зможе отримати джерельні коди проекту, оскільки буде наштовхуватись на дві помилки:

  1. невідомий сертифікат (вирішується одноразовим входом з доданням сертифікату в довірені)
  2. незареєстрований користувач (вирішується одноразовим входом з введенням та автоматичним збереженням реєстраційних даних клієнтом subversion).

Фільтрація по розширенню файлів

Можливі такі випадки, коли в репозитарії зберігаються не лише джерельні коди, а ще й супутня документація, файли опису, які не впливають на процес збирання. При цьому бот з базовим налаштуванням при оновленні подібних файлів буде все одно робити збірку. Щоб уникнути цього необхідно для початку створити об’єкт типу Callable (в простих варіантах функція підійде якнайкраще), який буде повертати істину у випадку, якщо збирання проекту необхідне. Так, для Java проекту, описаного в попередній статті, я використав:

1
2
3
4
5
6
7
8
9
import re
 
def checkIfBuildNeeded(change):
	regexp = re.compile('\.java$|\.idl$|\.jar$|build\.xml$',re.IGNORECASE)
 
	for name in change.files:
		if regexp.search(name):
			return True
	return False

Тепер слід вказати дану функцію як перевірку в налаштуваннях об’єкта Sheduler:

11
12
13
14
15
16
from buildbot.scheduler import Scheduler
 
c['schedulers'] = []
c['schedulers'].append(Scheduler(name="basic",
	fileIsImportant=checkIfBuildNeeded,
	builderNames=["quick"]))

Пересилання готових збірок

Уявімо, що бот в результаті процесу збирання генерує ще й готові до встановлення бінарні пакети, як, наприклад, .deb, .rpm, чи готує зрізи джерельних кодів, при цьому було б бажаним переслати файли з buildbot-клієнта на buildbot-сервер, де вони б знаходилися в загальнодоступній директорії. Можлива й зворотня ситуація: для перевірки деякого функціоналу необхідні сценарії, згенеровані іншим проектом. Для таких задач можна використати спеціальні кроки збирання FileUpload та FileDownload, що знаходяться в buildbot.steps.transfer. Ось невеличкий приклад використання одного з цих кроків:

from buildbot.steps.shell import ShellCommand
from buildbot.steps.transfer import FileUpload
 
f.addStep(ShellCommand(name="Package", command=["tar", "zxvf", "build.tar.gz", "build"]))
f.addStep(FileUpload(slavesrc="build.tar.gz",
    masterdest="~/public_html/build"+datetime.now().strftime("%Y%m%d-%H%M%S")+"tar.gz"))

Окрім того, що пакет буде надісланий на сервер, він ще й матиме унікальну назву,що вказуватиме на час його створення. Це можливо завдяки тому, що кожен об’єкт-крок виконується інтерпретатором в момент надсилання його клієнту, в даному випадку генеруючи їм’я файлу на сервері.

Залежні збірки

Уявімо, що зібраний на відповідному клієнті пакет повинен бути встановлений на окремій тестовій машині, де буде детально протестований автоматичними засобами. В такому випадку зручно використовувати залежні збірки. Вони дозволять не виконувати тестів у випадку неуспішного збирання пакету. Щоб скористатись даною можливістю, слід в кроки збирання додати об’єкт Trigger, який буде викликати відповідний процес збирання через об’єкт Sheduler.

from buildbot.steps.trigger import Trigger
     f.addStep(Trigger(schedulerNames=['package'],
                       waitForFinish=True,
                       updateSourceStamp=True))

Завдяки кроку Trigger також можна запускати процеси одночасно на кількох машинах.

Корисні посилання

Наостанок, якщо вам до вподоби автоматизація процесів вашої роботи, і ви бачите зручність у використанні Buildbot-а в якості системи неперервної інтеграції, автоматизації та інших подібних операцій, під рукою повинна бути література, в якій можна було б отримати необхідні знання. Сподіваюсь, ці посилання зекономлять вам купу часу:

Веб-сайт проекту: http://buildbot.net
Документація користувача: /usr/share/buildbot/buildbot.html в кожному Linux дистрибутиві зі встановленим Buildbot’ом.
Документація розробника: http://buildbot.sourceforge.net/API-0.7.5/

На цьому я завершую цикл статей про чудовий інструмент в автоматизації та неперервній інтеграції — Buildbot. Попереду ще багато інструментів, які не менш важливі для втілення ваших мрій у рядках коду. Не перемикайтесь!