1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
|
buildbot(7) "" "Services Administration"
# NAME
buildbot - master instances creation, upgrade and management
# DESCRIPTION
Buildbot master instances are located under individual folders in
_/var/lib/buildbot/masters_. This manual explains how to manage them.
# CREATION
To create a new Buildbot master instance named _$NAME_, use the following
commands:
```
buildbot create-master /var/lib/buildbot/masters/$NAME
chown -R buildbot: /var/lib/buildbot/masters/$NAME
```
After which, you should review and edit the _master.cfg.sample_ configuration
file located in the master base directory and rename it to _master.cfg_.
The configuration file syntax is extensively described in
_/usr/share/doc/buildbot/html_ (installed with the *buildbot-doc* package).
*note*
In the default configuration Buildbot uses a file-based SQLite
database, stored in the _state.sqlite_ file of the master's base
directory. If you want to use another database engine, you may need to
install additional packages (e.g., *postgresql* and *python3-psycopg2*
to use PostgreSQL). Refer to the Buildbot documentation for the
associated _master.cfg_ syntax.
*ATTENTION*
The new Buildbot web dashboard cannot be integrated into Debian yet
because of policy violation (See: bug #883529). In the meantime, if you
want to enable it in your configuration, it can be installed with *pip3
install buildbot-www*.
You may use the following command to validate your configuration file:
```
buildbot checkconfig /var/lib/buildbot/masters/$NAME/master.cfg
```
Once you are satisfied with your configuration file, you may start the Buildbot
master instance. Depending on the init system you use, this is done differently.
## systemd
To start the instance:
```
systemctl start buildbot@$NAME.service
```
To enable automatic start on boot:
```
systemctl enable buildbot@$NAME.service
```
If you want to tune the way the instance is started (e.g., to change
the user that runs the process), you may use a systemd drop-in:
```
mkdir -p /etc/systemd/system/buildbot@$NAME.service.d
editor /etc/systemd/system/buildbot@$NAME.service.d/user.conf
```
With the following contents:
```
[Service]
User=my-user
Group=my-group
```
## sysvinit
First, you need to edit _/etc/default/buildbot_ and configure your instance. The
syntax is pretty self explanatory, but here is an example:
```
# 1-enabled, 0-disabled
MASTER_ENABLED[1]=1
# short name printed on start/stop
MASTER_NAME[1]="$NAME"
# user to run master as
MASTER_USER[1]="buildbot"
# basedir to master (absolute path)
MASTER_BASEDIR[1]="/var/lib/buildbot/masters/$NAME"
# buildbot options
MASTER_OPTIONS[1]=""
# prefix command, i.e. nice, linux32, dchroot
MASTER_PREFIXCMD[1]=""
```
After which, you may start the instance:
```
service buildbot start $NAME
```
By default, it will automatically start on boot.
# UPGRADE
By default, Buildbot master instances are automatically upgraded when installing
new versions. This consists in the following operations for each instance:
- The instance is stopped.
- _buildbot upgrade-master /var/lib/buildbot/masters/$NAME_ is executed.
- The instance is started again.
You may disable the automatic upgrade globally by running:
```
dpkg-reconfigure buildbot
```
Or for a specific master instance by creating a _.no-auto-upgrade_ file in its
base directory:
```
touch /var/lib/buildbot/masters/$NAME/.no-auto-upgrade
```
In any case, the upgrade operation is mandatory and Buildbot will fail to
restart an instance that has not been upgraded.
After upgrading, you will find that Buildbot has created a new
_master.cfg.sample_ file in the instance base directory. You can review it and
check the differences with your own configuration file. But in most cases, it
is safe to delete this file.
## upgrading from 0.8.x
If upgrading from a 0.8.x version, all master instances in must be manually
migrated. This may require a number of changes to the master configuration.
Please refer to the "nine-upgrade" chapter in the documentation for details.
Once you have finished migrating, you may delete the _.no-auto-upgrade_ files
to allow further automatic upgrades to proceed.
The _buildmaster_ service has been renamed to _buildbot_.
Also, to avoid spurious errors on boot, the automatic start of each existing
instance has been "disabled" in _/etc/default/buildbot_ (which was renamed from
_/etc/default/buildmaster_). If you which to use systemd to manage your
instances, please refer to the *CREATION* section of this manual.
# FILES
_/var/lib/buildbot/masters/$NAME_
Working directory for the _$NAME_ Buildbot master instance.
_/etc/systemd/system/buildbot@$NAME.service.d_
Directory containing customization drop-ins for the _$NAME_ Buildbot
master instance service.
_/etc/default/buildbot_
The master instances services definition for sysvinit users.
# SEE ALSO
*buildbot*(1), *systemctl*(1), *systemd.unit*(5), *service*(8)
# AUTHOR
Robin Jarry <robin@jarry.cc>
|
