Mercurial > hg > autobot

comparison README.txt @ 204:5f188d2a36aa

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
write how the .ini files work
author Jeff Hammel <jhammel@mozilla.com>
date Wed, 02 Feb 2011 18:17:07 -0800
parents bba97450cbc2
children 3e5d1c1e302d
comparison
equal deleted inserted replaced
203:1e1467529854 204:5f188d2a36aa
57 command the generated bot will have a ``restart_buildbot.py`` script 57 command the generated bot will have a ``restart_buildbot.py`` script
58 that will stop and start both the master and slave and (if debug is 58 that will stop and start both the master and slave and (if debug is
59 set) remove the log as well. 59 set) remove the log as well.
60 60
61 The generated ``master.cfg`` file reads values from an ``master.ini`` 61 The generated ``master.cfg`` file reads values from an ``master.ini``
62 file in the same directory 62 file in the same directory. The master.ini contains a number of
63 different sections:
64
65 * ``[:master:]`` contains the top level configuration for the master
66 as well as default settings for slaves
67 * sections like ``[slave:slavename]`` indicate a slave of name
68 ``slavename``
69 * other sections are construction parameters for factories
70
71 The format of the ``.ini`` file is detailed in the subsequent
72 section. You may change the .ini file used by editing the
73 ``master.cfg`` file, or, if for whatever reason you don't want to use
74 an .ini file you can construct the appropriate configuration therein
75 yourself.
76
77 An overview of the build status is detailed at the waterfall display,
78 by default at http://localhost:8010/waterfall . To force a build,
79 click on the desired builder and there will be a force build button
80 towards the bottom.
63 81
64 It is important to remember that continuous integration is a safety 82 It is important to remember that continuous integration is a safety
65 net, not a first line of defense. 83 net, not a first line of defense. In other words, continue to check your code
84 *before* sending it to autobot.
85
86 .ini file format
87 ----------------
88
89 As stated above, a ``master.ini`` file contains three different kinds
90 of sections:
91
92 * ``[:master:]`` contains the top level configuration for the master
93 as well as default settings for slaves
94 * sections like ``[slave:slavename]`` indicate a slave of name
95 ``slavename``
96 * other sections are construction parameters for factories
97
98 What goes in each of these?
99
100 ``:master:`` The master section contains parameters appropriate to the
101 buildmaster:
102
103 * slaveport: which port to listen for the slaves on
104 * htmlport: which port to serve the waterfall display on
105 * pollInterval: how often to poll the repositories, in seconds [DEFAULT: 60]
106 * treeStable: how long to wait before the tree settles down before
107 building [DEFAULT: 60]
108
109 The other defaults may be seen by running ``create-autobot-master --help``.
110
111 Other parameters given in the ``[:master:]`` section are used as the
112 baseline defaults for each slave. They may be overridden in each
113 ``slave:`` section
114
115 ----
116
117 ``slave:`` parameters for each slave:
118
119 * password: each slave *must* have a password. Unless there's a
120 reason to have a password per slave, its probably better to put this
121 in the ``:master:`` section
122
123 * factories: space-separated list of factories to run on that slave.
124 If the special value ``*`` is used, all factories will be run. You
125 can view the factories available with
126 ``create-autobot --list-factories``. The factory name corresponds to
127 the directory (or module) name in ``autobot.projects``.
128
129 * os: the operating system of the slave. Should be one of linux, win,
130 or mac (though see TODO about future use of MozInfo making this
131 obselescent). You probably *shouldn't* have a default key for this
132 in the ``:master:`` section (though autobot won't try to stop you!).
133
134 ----
135
136 factory sections: Each parameter in a factory section is used as a
137 constructor (``__init__``) keyword argument when they are created in
138 the ``master.cfg``. So a factory section like::
139
140 [foo]
141 bar = fleem
142 baz = another parameter
143
144 will invoke the foo factory (lets say it maps to ``MyFooFactory``) on
145 each slave like::
146
147 MyFooFactory(**dict(bar='fleem', baz='another parameter'))
148
149 In addition, if a factory has a special key, ``platform``, the slave
150 will pass its platform information when instantiating a factory.
151 Currently, this is a dict with a single key, ``os``, but more may be
152 added as needed. As noted in the TODO below, ideally this would be
153 deprecated entirely by MozInfo but such is the interim solution.
66 154
67 155
68 Projects 156 Projects
69 -------- 157 --------
70 158
96 Let me know! I'd like to make autobot a solution that works for all 184 Let me know! I'd like to make autobot a solution that works for all
97 stake-holders, and if you're reading this, that means you! 185 stake-holders, and if you're reading this, that means you!
98 186
99 jhammel@mozilla.com 187 jhammel@mozilla.com
100 188
189
101 TODO 190 TODO
102 ---- 191 ----
103 192
104 No software of any size is ever finished. Here are a few things I 193 No software of any size is ever finished. Here are a few things I
105 would like to add: 194 would like to add:
107 * singular checkout of repos on slaves: the slaves should have a 196 * singular checkout of repos on slaves: the slaves should have a
108 singular master repo that is checked out once for each repo URL, 197 singular master repo that is checked out once for each repo URL,
109 branch pair. It is then updated as the slaves need and (e.g.) 198 branch pair. It is then updated as the slaves need and (e.g.)
110 cloned from there. This should effectively minimize fetch time. 199 cloned from there. This should effectively minimize fetch time.
111 200
112 * slaves should have .ini files indicated by the config 201 * use (as yet non-existent) MozInfo package on the slave: instead of
202 specifying the operating system, etc on the master, MozInfo should
203 determine the applicable information from introspection