"Fossies" - the Fresh Open Source Software Archive  

Source code changes of the file "docs/manual/installation/misc.rst" between
buildbot-3.0.2.tar.gz and buildbot-3.1.0.tar.gz

About: Buildbot is a continuous integration testing framework (Python-based). It supports also automation of complex build systems, application deployment, and management of sophisticated software-release processes.

misc.rst  (buildbot-3.0.2):misc.rst  (buildbot-3.1.0)
skipping to change at line 19 skipping to change at line 19
Both the buildmaster and the worker run as daemon programs. Both the buildmaster and the worker run as daemon programs.
To launch them, pass the working directory to the :command:`buildbot` and :comma nd:`buildbot-worker` commands, as appropriate: To launch them, pass the working directory to the :command:`buildbot` and :comma nd:`buildbot-worker` commands, as appropriate:
.. code-block:: bash .. code-block:: bash
# start a master # start a master
buildbot start [ BASEDIR ] buildbot start [ BASEDIR ]
# start a worker # start a worker
buildbot-worker start [ WORKER_BASEDIR ] buildbot-worker start [ WORKER_BASEDIR ]
The *BASEDIR* is option and can be omitted if the current directory contains the buildbot configuration (the :file:`buildbot.tac` file). The *BASEDIR* is optional and can be omitted if the current directory contains t he buildbot configuration (the :file:`buildbot.tac` file).
.. code-block:: bash .. code-block:: bash
buildbot start buildbot start
This command will start the daemon and then return, so normally it will not prod uce any output. This command will start the daemon and then return, so normally it will not prod uce any output.
To verify that the programs are indeed running, look for a pair of files named : file:`twistd.log` and :file:`twistd.pid` that should be created in the working d irectory. To verify that the programs are indeed running, look for a pair of files named : file:`twistd.log` and :file:`twistd.pid` that should be created in the working d irectory.
:file:`twistd.pid` contains the process ID of the newly-spawned daemon. :file:`twistd.pid` contains the process ID of the newly-spawned daemon.
When the worker connects to the buildmaster, new directories will start appearin g in its base directory. When the worker connects to the buildmaster, new directories will start appearin g in its base directory.
skipping to change at line 47 skipping to change at line 47
@reboot buildbot start [ BASEDIR ] @reboot buildbot start [ BASEDIR ]
When you run :command:`crontab` to set this up, remember to do it as the buildma ster or worker account! When you run :command:`crontab` to set this up, remember to do it as the buildma ster or worker account!
If you add this to your crontab when running as your regular account (or worse y et, root), then the daemon will run as the wrong user, quite possibly as one wit h more authority than you intended to provide. If you add this to your crontab when running as your regular account (or worse y et, root), then the daemon will run as the wrong user, quite possibly as one wit h more authority than you intended to provide.
It is important to remember that the environment provided to cron jobs and init scripts can be quite different than your normal runtime. It is important to remember that the environment provided to cron jobs and init scripts can be quite different than your normal runtime.
There may be fewer environment variables specified, and the :envvar:`PATH` may b e shorter than usual. There may be fewer environment variables specified, and the :envvar:`PATH` may b e shorter than usual.
It is a good idea to test out this method of launching the worker by using a cro n job with a time in the near future, with the same command, and then check :fil e:`twistd.log` to make sure the worker actually started correctly. It is a good idea to test out this method of launching the worker by using a cro n job with a time in the near future, with the same command, and then check :fil e:`twistd.log` to make sure the worker actually started correctly.
Common problems here are for :file:`/usr/local` or :file:`~/bin` to not be on yo ur :envvar:`PATH`, or for :envvar:`PYTHONPATH` to not be set correctly. Common problems here are for :file:`/usr/local` or :file:`~/bin` to not be on yo ur :envvar:`PATH`, or for :envvar:`PYTHONPATH` to not be set correctly.
Sometimes :envvar:`HOME` is messed up too. If using systemd to launch :command:` Sometimes :envvar:`HOME` is messed up too. If using systemd to launch :command:`
buildbot-worker` it may be a good idea to specify a fixed :envvar:`PATH` using t buildbot-worker`, it may be a good idea to specify a fixed :envvar:`PATH` using
he :envvar:`Environment` directive, the :envvar:`Environment` directive
see `systemd unit file example <https://github.com/buildbot/buildbot-contrib/blo (see `systemd unit file example <https://github.com/buildbot/buildbot-contrib/bl
b/master/worker/contrib/systemd/buildbot-worker%40.service>`_ ob/master/worker/contrib/systemd/buildbot-worker%40.service>`_).
Some distributions may include conveniences to make starting buildbot at boot ti me easy. Some distributions may include conveniences to make starting buildbot at boot ti me easy.
For instance, with the default buildbot package in Debian-based distributions, y ou may only need to modify :file:`/etc/default/buildbot` (see also :file:`/etc/i nit.d/buildbot`, which reads the configuration in :file:`/etc/default/buildbot`) . For instance, with the default buildbot package in Debian-based distributions, y ou may only need to modify :file:`/etc/default/buildbot` (see also :file:`/etc/i nit.d/buildbot`, which reads the configuration in :file:`/etc/default/buildbot`) .
Buildbot also comes with its own init scripts that provide support for controlli ng multi-worker and multi-master setups (mostly because they are based on the in it script from the Debian package). Buildbot also comes with its own init scripts that provide support for controlli ng multi-worker and multi-master setups (mostly because they are based on the in it script from the Debian package).
With a little modification these scripts can be used both on Debian and RHEL-bas ed distributions and may thus prove helpful to package maintainers who are worki ng on buildbot (or those that haven't yet split buildbot into master and worker packages). With a little modification, these scripts can be used on both Debian and RHEL-ba sed distributions. Thus, they may prove helpful to package maintainers who are w orking on buildbot (or to those who haven't yet split buildbot into master and w orker packages).
.. code-block:: bash .. code-block:: bash
# install as /etc/default/buildbot-worker # install as /etc/default/buildbot-worker
# or /etc/sysconfig/buildbot-worker # or /etc/sysconfig/buildbot-worker
worker/contrib/init-scripts/buildbot-worker.default worker/contrib/init-scripts/buildbot-worker.default
# install as /etc/default/buildmaster # install as /etc/default/buildmaster
# or /etc/sysconfig/buildmaster # or /etc/sysconfig/buildmaster
master/contrib/init-scripts/buildmaster.default master/contrib/init-scripts/buildmaster.default
skipping to change at line 82 skipping to change at line 82
# ... and tell sysvinit about them # ... and tell sysvinit about them
chkconfig buildmaster reset chkconfig buildmaster reset
# ... or # ... or
update-rc.d buildmaster defaults update-rc.d buildmaster defaults
.. _Launching-worker-as-Windows-service: .. _Launching-worker-as-Windows-service:
Launching worker as Windows service Launching worker as Windows service
----------------------------------- -----------------------------------
You can find information about installation of Buildbot as Windows service here You can find information about installation of Buildbot as Windows service in
`RunningBuildbotOnWindows <http://trac.buildbot.net/wiki/RunningBuildbotOnWindow s>`_. `RunningBuildbotOnWindows <http://trac.buildbot.net/wiki/RunningBuildbotOnWindow s>`_.
Recent version of Buildbot worker has simplified configuration for Windows servi ce. A recent version of Buildbot worker has simplified the configuration for a Windo ws service.
.. code-block:: bat .. code-block:: bat
buildbot_worker_windows_service.exe --user YOURDOMAIN\theusername --password thepassword --startup auto install buildbot_worker_windows_service.exe --user YOURDOMAIN\theusername --password thepassword --startup auto install
automatically adds user rights to run Buildbot as service. The above command automatically adds user rights to run Buildbot as service.
.. _Logfiles: .. _Logfiles:
Logfiles Logfiles
-------- --------
While a buildbot daemon runs, it emits text to a logfile, named :file:`twistd.lo g`. While a buildbot daemon runs, it emits text to a logfile, named :file:`twistd.lo g`.
A command like ``tail -f twistd.log`` is useful to watch the command output as i t runs. A command like ``tail -f twistd.log`` is useful to watch the command output as i t runs.
The buildmaster will announce any errors with its configuration file in the logf ile, so it is a good idea to look at the log at startup time to check for any pr oblems. The buildmaster will announce any errors with its configuration file in the logf ile, so it is a good idea to look at the log at startup time to check for any pr oblems.
skipping to change at line 122 skipping to change at line 122
buildbot stop [ BASEDIR ] buildbot stop [ BASEDIR ]
# or # or
buildbot-worker stop [ WORKER_BASEDIR ] buildbot-worker stop [ WORKER_BASEDIR ]
This simply looks for the :file:`twistd.pid` file and kills whatever process is identified within. This simply looks for the :file:`twistd.pid` file and kills whatever process is identified within.
At system shutdown, all processes are sent a ``SIGKILL``. At system shutdown, all processes are sent a ``SIGKILL``.
The buildmaster and worker will respond to this by shutting down normally. The buildmaster and worker will respond to this by shutting down normally.
The buildmaster will respond to a ``SIGHUP`` by re-reading its config file. The buildmaster will respond to a ``SIGHUP`` by re-reading its config file.
Of course, this only works on Unix-like systems with signal support, and won't w ork on Windows. Of course, this only works on Unix-like systems with signal support and not on W indows.
The following shortcut is available: The following shortcut is available:
.. code-block:: bash .. code-block:: bash
buildbot reconfig [ BASEDIR ] buildbot reconfig [ BASEDIR ]
When you update the Buildbot code to a new release, you will need to restart the When you update the Buildbot code to a new release, you will need to restart the
buildmaster and/or worker before it can take advantage of the new code. buildmaster and/or worker before they can take advantage of the new code.
You can do a :samp:`buildbot stop {BASEDIR}` and :samp:`buildbot start {BASEDIR} You can do a :samp:`buildbot stop {BASEDIR}` and :samp:`buildbot start {BASEDIR}
` in quick succession, or you can use the ``restart`` shortcut, which does both ` in succession, or you can use the ``restart`` shortcut, which does both steps
steps for you: for you:
.. code-block:: bash .. code-block:: bash
buildbot restart [ BASEDIR ] buildbot restart [ BASEDIR ]
Workers can similarly be restarted with: Workers can similarly be restarted with:
.. code-block:: bash .. code-block:: bash
buildbot-worker restart [ BASEDIR ] buildbot-worker restart [ BASEDIR ]
There are certain configuration changes that are not handled cleanly by ``buildb ot reconfig``. There are certain configuration changes that are not handled cleanly by ``buildb ot reconfig``.
If this occurs, ``buildbot restart`` is a more robust tool to fully switch over to the new configuration. If this occurs, ``buildbot restart`` is a more robust way to fully switch over t o the new configuration.
``buildbot restart`` may also be used to start a stopped Buildbot instance. ``buildbot restart`` may also be used to start a stopped Buildbot instance.
This behaviour is useful when writing scripts that stop, start and restart Build bot. This behavior is useful when writing scripts that stop, start, and restart Build bot.
A worker may also be gracefully shutdown from the web UI. A worker may also be gracefully shutdown from the web UI.
This is useful to shutdown a worker without interrupting any current builds. This is useful to shutdown a worker without interrupting any current builds.
The buildmaster will wait until the worker has finished all its current builds, and will then tell the worker to shutdown. The buildmaster will wait until the worker has finished all its current builds, and will then tell the worker to shutdown.
.. [#f1] .. [#f1]
This ``@reboot`` syntax is understood by Vixie cron, which is the flavor usua lly provided with Linux systems. This ``@reboot`` syntax is understood by Vixie cron, which is the flavor usua lly provided with Linux systems.
Other unices may have a cron that doesn't understand ``@reboot`` Other unices may have a cron that doesn't understand ``@reboot``
 End of changes. 10 change blocks. 
18 lines changed or deleted 18 lines changed or added

Home  |  About  |  Features  |  All  |  Newest  |  Dox  |  Diffs  |  RSS Feeds  |  Screenshots  |  Comments  |  Imprint  |  Privacy  |  HTTP(S)