Спатрэбілася мне наладзіць працэс зборкі і дастаўкі на сайт пакетаў праграм з Git-рэпазітара. І убачыўшы, ні так даўно, тут на Хабре артыкул па buildbot (спасылка ў канцы) вырашыў для гэтага паспрабаваць яго і прымяніць.
Бо buildbot – гэта размеркаваная сістэма, то будзе лагічным пад кожную архітэктуру і аперацыёнку зрабіць асобны зборачны хост. У нашым выпадку гэта будуць LXC-кантэйнеры (у выпадку linux) і qemu (у выпадку windows):
vm-srv-build1 - centos 7, тут будзе buildbot майстар (master) і адзін з працоўных (worker)
vm-srv-build2 — debian 10, для зборкі пакетаў DEB
vm-srv-build3 - windows 10, для зборкі, самі разумееце, пад што
Збіраць будзем Rac GUI - Графічная морда да 1С rac для кіравання кластарам сервераў. Пад лінукс будуць выкарыстоўвацца штатныя сродкі пад кожную АС, для зборкі exe-файла пад windows з tcl-скрыпту выкарыстоўваецца. freewrap.
Ўстаноўка
GNU / Linux
Па ўстаноўцы, дакументацыі ў сетцы дастаткова 1,2. Ды і асаблівых праблем яна не выклікае:
Для майстра:
Вядома, дакладней будзе сабраць пакеты пад кожную АС, але гэта ў рамкі артыкула не ўваходзіць. Таксама апусцім апісанне налады кантэйнераў для працы, адзначу толькі, што выкарыстоўваю ProxMox VE. І яшчэ спатрэбіцца ўсталяваць пакеты пад кожную вось патрэбныя для зборкі (centos: rpmdevtools і г.д; debian: build-essential, dh-make, pbuilder і г.д.)
Зборка праектаў і сэрвісы buildbot будуць запускацца ад імя непрывілеяванага карыстальніка, таму неабходна яго стварыць на ўсіх хастах, якія ўдзельнічаюць у працэсе:
adduser buildbot
Далей наладзім аўтаматычны запуск сэрвісаў, адпаведна на кожным з хастоў (кантэйнераў):
Пасля гэтага, можна стварыць інфраструктуру каталогаў для "працоўных" (на ўсіх хастах), для гэтага рэгіструецца пад карыстальнікам buildbot і выконваем наступныя каманды:
На першым хасце vm-srv-build1:
su - buildbot
mkdir /home/buildbot/worker
cd ~
buildbot-worker create-worker --umask=0o22 --keepalive=60 worker vm-srv-build1:4000 CentOS 123456
На другім хасце vm-srv-build2:
su - buildbot
mkdir /home/buildbot/worker
cd ~
buildbot-worker create-worker --umask=0o22 --keepalive=60 worker vm-srv-build1:4000 Debian-10 123456
На хастах-працоўных службу buildbot-worker можна запусціць
systemctl start buildbot-worker
MS Windows
У якасці "працоўнага" для зборкі пад windows, будзе скарыстана віртуальная машына з апошнім рэлізам Win10.
Для працы спатрэбіцца:
Пасля таго, як усталюецца ўсё вышэйпералічанае, можна паставіць і сам buildbot:
pip install buildbot-worker
Створым працоўны каталог
md c:worker
І запусцім
buildbot-worker start c:worker
Калі ўсё працуе (гл. лог c:workertwistd.log), то можна нашага «працоўнага», зарэгістраваць як службу, дадаўшы ў рэестр пункт з працоўным каталогам (каманды выконваюцца ў powershell запушчаным ад імя адміністратара):
З "працоўнымі" на гэтым усё, далей іх можна не чапаць, усё кіраванне ідзе з майстра.
Настройка майстра
Для пачатку, створым інфраструктуру для майстра (на галоўным хасце), для гэтага рэгіструецца пад карыстачом buildbot і выконваем наступныя каманды:
su - buildbot
mkdir /home/buildbot/master
cd ~
buildbot create-master master
Для гатовых пакетаў створым каталог builds
mkdir /home/buildbot/builds
У каталогу /home/buildbot/master/ быў створаны файл master.cfg. Дадзены файл уяўляе сабой код на python і ўтрымоўвае апісанне ўсіх механізмаў працы сістэмы, з ім і будзем працаваць у наступным.
Для аўтаматызацыі зборкі пакетаў розных версій, каб не прыходзілася лазіць у код файла master.cfg, у асноўным скрыпце праграмы rac_gui.tcl у загалоўку, дададзены радкі з бягучымі версіяй і рэлізам:
І на аснове гэтых радкоў buildbot будзе нумараваць пакеты. Для вырывання дадзеных, выкарыстоўваецца выклік кансольнага grep. У buildbot проста так нельга апярэдзіць зменныя для "працоўных" (ва ўсякім разе, я не знайшоў як). Для гэтага служаць уласцівасці (property). Г.зн. у зборачны працэс, дадаем крокі па вызначэнні версіі і рэлізу і адпаведна, усталёўваны ўласцівасці version і release. Уласцівасці можна ўсталёўваць рознымі спосабамі, у дадзеным выпадку гэта выклік кансольнай каманды:
# Добавим определение версии из основного файла
rac_gui_build_RPM.addStep(
steps.SetPropertyFromCommand(
command="grep version ../rac-gui/rac_gui.tcl | grep -oE 'b[0-9]{1,2}.[0-9]{1,2}.[0-9]{1,2}b'", property="version"
)
)
# Добавим определение релиза из основного файла
rac_gui_build_RPM.addStep(
steps.SetPropertyFromCommand(
command="grep release ../rac-gui/rac_gui.tcl | grep -oE 'b[0-9]{1,3}b'", property="release"
)
)
Падстаўляць атрыманыя значэнні можна шляхам выкліку util.Interpolate().
Для ўсталёўкі карэктных нумароў рэлізу і версіі выкарыстоўваецца выклік стандарнага sed, г.зн. каманда замяняе значэння ўнутры spec-файла на неабходныя
На гэтым з RPM скончылі. Цяпер прыступім да апісання алгарытму зборкі DEB-пакета. Бо працэсы зборкі пакетаў пад розныя сістэмы незалежныя сябар ад сябра, то і шматлікія крокі будуць паўторацца.
rac_gui_build_DEB = util.BuildFactory()
rac_gui_build_DEB.addStep(steps.Git(
repourl = 'https://bitbucket.org/svk28/rac-gui.git',
haltOnFailure = True,
submodules = True,
mode='full',
workdir='build',
progress = True)
)
# Добавим определение версии из основного файла
rac_gui_build_DEB.addStep(
steps.SetPropertyFromCommand(
command="grep version rac_gui.tcl | grep -oE 'b[0-9]{1,2}.[0-9]{1,2}.[0-9]{1,2}b'", property="version"
)
)
# Добавим определение релиза из основного файла
rac_gui_build_DEB.addStep(
steps.SetPropertyFromCommand(
command="grep release rac_gui.tcl | grep -oE 'b[0-9]{1,3}b'", property="release"
)
)
# Переименуем запускаемый файл
rac_gui_build_DEB.addStep(steps.ShellCommand(
command=["mv", "rac_gui.tcl", "racgui"]))
Для RPM-пакета частка ніжэйзгаданых працэдур робіцца самім rpm пры зборцы і апісаны ўнутры спека, для дэбіяна даводзіцца гэта рабіць тут:
# Поменяем пути к библиотекам
rac_gui_build_DEB.addStep(steps.ShellCommand(
command=["sed", "-i", "s+^set dir(lib)+set dir(lib) /usr/share/rac-gui/lib ;#+g", "racgui"]))
# Поменяем пути к файлам
rac_gui_build_DEB.addStep(steps.ShellCommand(
command=["sed", "-i", "s+[pwd]+/usr/share/rac-gui+g", "racgui"]))
# заархивируем исходники
rac_gui_build_DEB.addStep(steps.ShellCommand(
command=["tar", "czf", util.Interpolate("../rac-gui_%(prop:version)s.orig.tar.gz"), "."]))
# Соберём пакет
rac_gui_build_DEB.addStep(steps.ShellCommand(
command=["dpkg-buildpackage"]))
# Скопируем файл на мастер
rac_gui_build_DEB.addStep(
steps.FileUpload(
workersrc=util.Interpolate("../rac-gui_%(prop:version)s-%(prop:release)s_amd64.deb"),
masterdest=util.Interpolate("/home/buildbot/builds/rac-gui_%(prop:version)s-%(prop:release)s_amd64.deb")
)
)
rac_gui_build_DEB.addStep(
steps.MasterShellCommand(
command=["/usr/local/bin/deploy-ftp.tcl",
util.Interpolate("--local-file=/home/buildbot/builds/rac-gui_%(prop:version)s-%(prop:release)s_amd64.deb"),
util.Interpolate("--remote-file=uploads/rac-gui/rac-gui_%(prop:version)s-%(prop:release)s_amd64.deb")]
)
)
Захоўваем файл і можна паспрабаваць запусціць службу майстра:
systemctl restart buildbot-master
У логу пракантралюем што з канфігам усё ў парадку і ўсё працуе ў штатным рэжыме. Усе нашы працаўнікі павінны зараз падлучыцца, пра што ў логу »»'/home/buildbot/master/twistd.log»»' будзе радасна паведамлена:
2019-07-24 16:50:35+0300 [-] Loading buildbot.tac...
2019-07-24 16:50:35+0300 [-] Loaded.
2019-07-24 16:50:35+0300 [-] twistd 19.2.1 (/usr/bin/python3.6 3.6.8) starting up.
2019-07-24 16:50:35+0300 [-] reactor class: twisted.internet.epollreactor.EPollReactor.
2019-07-24 16:50:35+0300 [-] Starting BuildMaster -- buildbot.version: 2.3.1
2019-07-24 16:50:35+0300 [-] Loading configuration from '/home/buildbot/master/master.cfg'
2019-07-24 16:50:36+0300 [-] /usr/local/lib/python3.6/site-packages/buildbot/config.py:90: buildbot.config.ConfigWarning: [0.9.0 and later] `buildbotNetUsageData` is not configured and defaults to basic.
This parameter helps the buildbot development team to understand the installation base.
No personal information is collected.
Only installation software version info and plugin usage is sent.
You can `opt-out` by setting this variable to None.
Or `opt-in` for more information by setting it to "full".
2019-07-24 16:50:36+0300 [-] Setting up database with URL 'sqlite:/state.sqlite'
2019-07-24 16:50:36+0300 [-] setting database journal mode to 'wal'
2019-07-24 16:50:36+0300 [-] adding 1 new services, removing 0
2019-07-24 16:50:36+0300 [-] adding 1 new change_sources, removing 0
2019-07-24 16:50:36+0300 [-] gitpoller: using workdir '/home/buildbot/master/gitpoller-work'
2019-07-24 16:50:36+0300 [-] adding 3 new builders, removing 0
2019-07-24 16:50:36+0300 [-] adding 1 new schedulers, removing 0
2019-07-24 16:50:36+0300 [-] initializing www plugin 'waterfall_view'
2019-07-24 16:50:36+0300 [-] initializing www plugin 'console_view'
2019-07-24 16:50:36+0300 [-] initializing www plugin 'grid_view'
2019-07-24 16:50:36+0300 [-] NOTE: www plugin 'sitenav' is installed but not configured
2019-07-24 16:50:36+0300 [-] initializing www plugin 'waterfall_view'
2019-07-24 16:50:36+0300 [-] initializing www plugin 'console_view'
2019-07-24 16:50:36+0300 [-] initializing www plugin 'grid_view'
2019-07-24 16:50:36+0300 [-] NOTE: www plugin 'sitenav' is installed but not configured
2019-07-24 16:50:36+0300 [-] BuildbotSite starting on 80
2019-07-24 16:50:36+0300 [-] Starting factory <buildbot.www.service.BuildbotSite object at 0x7fe31c2657b8>
2019-07-24 16:50:36+0300 [-] adding 3 new workers, removing 0
2019-07-24 16:50:36+0300 [-] PBServerFactory starting on 4000
2019-07-24 16:50:36+0300 [-] Starting factory <twisted.spread.pb.PBServerFactory object at 0x7fe31c147470>
2019-07-24 16:50:37+0300 [-] BuildMaster is running
2019-07-24 16:50:37+0300 [-] buildbotNetUsageData: sending {'installid': 'b6193b126b96689351d2fe95787c5a03fc0879f9', 'versions': {'Python': '3.6.8', 'Buildbot': '2.3.1', 'Twisted': '19.2.1'}, 'platform': {'platform': 'Linux-4.15.18-10- pve-x86_64-with-centos-7.6.1810-Core', 'system': 'Linux', 'machine': 'x86_64', 'processor': 'x86_64', 'python_implementation': 'CPython', 'version': '#1 SMP PVE 4.15.18-32', 'distro': 'centos:7'}, 'plugins': {'buildbot/worker/base/Worker': 3, 'buildbot/config/BuilderConfig': 3, 'buildbot/schedulers/basic/SingleBranchScheduler': 1, 'buildbot/reporters/mail/MailNotifier': 1, 'buildbot/changes/gitpoller/GitPoller': 1, 'buildbot/steps/worker/MakeDirectory': 1, 'buildbot/steps/source/git/Git': 3, 'buildbot/steps/shell/ShellCommand': 9, 'buildbot/steps/package/rpm/rpmbuild/RpmBuild': 1}, 'db': 'sqlite', 'mq': 'simple', 'www_plugins': ['waterfall_view', 'console_view', 'grid_view']}
2019-07-24 16:50:37+0300 [Broker,0,127.0.0.1] worker 'CentOS' attaching from IPv4Address(type='TCP', host='127.0.0.1', port=37332)
2019-07-24 16:50:37+0300 [Broker,0,127.0.0.1] Got workerinfo from 'CentOS'
2019-07-24 16:50:37+0300 [-] bot attached
2019-07-24 16:50:37+0300 [Broker,0,127.0.0.1] Worker CentOS attached to Rac-GUI-RPM-builder
2019-07-24 16:50:37+0300 [-] buildbotNetUsageData: buildbot.net said: ok
2019-07-24 16:50:39+0300 [Broker,1,192.168.55.15] worker 'Windows-10' attaching from IPv4Address(type='TCP', host='192.168.5.145', port=49831)
2019-07-24 16:50:39+0300 [Broker,1,192.168.55.15] Got workerinfo from 'Windows-10'
2019-07-24 16:50:40+0300 [-] bot attached
2019-07-24 16:50:40+0300 [Broker,1,192.168.55.15] Worker Windows-10 attached to Rac-GUI-WIN-builder
2019-07-24 16:50:41+0300 [Broker,2,192.168.55.99] worker 'Debian-10' attaching from IPv4Address(type='TCP', host='192.168.5.9', port=44430)
2019-07-24 16:50:41+0300 [Broker,2,192.168.55.99] Got workerinfo from 'Debian-10'
2019-07-24 16:50:41+0300 [-] bot attached
2019-07-24 16:50:41+0300 [Broker,2,192.168.55.99] Worker Debian-10 attached to Rac-GUI-DEB-builder
На гэтым працэс наладкі завершаны. Паглядзець бягучы стан можна праз вэб-морд. Дзе таксама можна паглядзець памылкі зборкі, штурхнуць які завіс працэс калі нешта пайшло ні так і г.д.
Адразу пасля запуску нашых рабацяг можна паглядзець праз меню "Builds" -> "Workers"
Пасля таго, як будзе праведзены першы працэс зборкі (г.зн. змены ў Git-рэпазітары), на першай старонцы з'явіцца стан працэсаў.
Калі тыцнуць мышай у патрэбны радок то адкрыецца старонка з бягучым станам дадзенага працэсу, дзе відаць што адбываецца, якія памылкі і г.д.