Skip to content
Browse files

Merge branch 'doc' of git://github.com/mgeisler/buildbot

  • Loading branch information...
2 parents b2fd75b + d2c4da9 commit 67e1507b3cd7dcd44a1565a07ea308274cfa8403 @djmitche djmitche committed Oct 1, 2012
View
4 master/docs/developer/master-slave.rst
@@ -58,7 +58,7 @@ The slave-side Bot object has the following remote methods:
``environ``
copy of the slaves environment
``system``
- OS the slave is running (extracted from pythons os.name)
+ OS the slave is running (extracted from Python's os.name)
``basedir``
base directory where slave is running
@@ -215,7 +215,7 @@ Runs a shell command on the slave. This command takes the following arguments:
A dictionary of environment variables to augment or replace the
existing environment on the slave. In this dictionary, ``PYTHONPATH``
is treated specially: it should be a list of path components, rather
- than a string, and will be prepended to the existing python path.
+ than a string, and will be prepended to the existing Python path.
``initial_stdin``
View
2 master/docs/manual/cfg-buildfactories.rst
@@ -365,7 +365,7 @@ Arguments:
pure-python modules.
``python``
- which python executable to use. This list will form the start of
+ which Python executable to use. This list will form the start of
the `argv` array that will launch trial. If you use this,
you should set ``trial`` to an explicit path (like
:file:`/usr/bin/trial` or :file:`./bin/trial`). The parameter defaults
View
4 master/docs/manual/cfg-buildslaves.rst
@@ -368,13 +368,13 @@ Libvirt
`libvirt <http://www.libvirt.org/>`_ is a virtualization API for interacting
with the virtualization capabilities of recent versions of Linux and other OSes.
-It is LGPL and comes with a stable C API, and python bindings.
+It is LGPL and comes with a stable C API, and Python bindings.
This means we know have an API which when tied to buildbot allows us to have slaves
that run under Xen, QEMU, KVM, LXC, OpenVZ, User Mode Linux, VirtualBox and VMWare.
The libvirt code in Buildbot was developed against libvirt 0.7.5 on Ubuntu Lucid. It
-is used with KVM to test python code on Karmic VM's, but obviously isn't limited to that.
+is used with KVM to test Python code on Karmic VM's, but obviously isn't limited to that.
Each build is run on a new VM, images are temporary and thrown away after each build.
Setting up libvirt
View
30 master/docs/manual/cfg-buildsteps.rst
@@ -264,7 +264,7 @@ The :bb:step:`Mercurial` build step performs a `Mercurial <http://selenic.com/me
(aka ``hg``) checkout or update.
Branches are available in two modes: ``dirname``, where the name of the branch is
-a suffix of the name of the repository, or ``inrepo``, which uses hg's
+a suffix of the name of the repository, or ``inrepo``, which uses Hg's
named-branches support. Make sure this setting matches your changehook, if you
have that installed. ::
@@ -285,7 +285,7 @@ The Mercurial step takes the following arguments:
``branchType``
either 'dirname' (default) or 'inrepo' depending on whether the
branch name should be appended to the ``repourl`` or the branch
- is a mercurial named branch and can be found within the ``repourl``.
+ is a Mercurial named branch and can be found within the ``repourl``.
``clobberOnBranchChange``
boolean, defaults to ``True``. If set and using inrepos branches,
@@ -345,11 +345,11 @@ The Git step takes the following arguments:
``submodules``
(optional): when initializing/updating a Git repository, this
- decides whether or not buildbot should consider git submodules.
+ decides whether or not buildbot should consider Git submodules.
Default: ``False``.
``shallow``
- (optional): instructs git to attempt shallow clones (``--depth
+ (optional): instructs Git to attempt shallow clones (``--depth
1``). If the user/scheduler asks for a specific revision, this
parameter is ignored.
@@ -412,10 +412,10 @@ The Git step takes the following arguments:
* ``getDescription=False``: disables this feature explicitly
* ``getDescription=True`` or empty ``dict()``: Run `git describe` with no args
- * ``getDescription={...}``: a dict with keys named the same as the git option.
+ * ``getDescription={...}``: a dict with keys named the same as the Git option.
Each key's value can be ``False`` or ``None`` to explicitly skip that argument.
- For the following keys, a value of ``True`` appends the same-named git argument:
+ For the following keys, a value of ``True`` appends the same-named Git argument:
* ``all`` : `--all`
* ``always``: `--always`
@@ -426,7 +426,7 @@ The Git step takes the following arguments:
* ``tags``: `--tags`
* ``dirty``: `--dirty`
- For the following keys, an integer or string value (depending on what git expects)
+ For the following keys, an integer or string value (depending on what Git expects)
will set the argument's parameter appropriately. Examples show the key-value pair:
* ``match=foo``: `--match foo`
@@ -704,7 +704,7 @@ The Repo step takes the following arguments:
(optional, defaults to ``None``): the repo tarball used for
fast bootstrap. If not present the tarball will be created
automatically after first sync. It is a copy of the ``.repo``
- directory which contains all the git objects. This feature helps
+ directory which contains all the Git objects. This feature helps
to minimize network usage on very big projects.
``jobs``
@@ -772,7 +772,7 @@ sources are coming from.
problems if the build process does not handle dependencies
properly (sometimes you must do a *clean build* to make sure
everything gets compiled), or if source files are deleted but
- generated files can influence test behavior (e.g. python's
+ generated files can influence test behavior (e.g. Python's
.pyc files), or when source directories are deleted but
generated files prevent CVS from removing them. Builds ought
to be correct regardless of whether they are done *from
@@ -1101,7 +1101,7 @@ The Mercurial step takes the following arguments:
``branchType``
either 'dirname' (default) or 'inrepo' depending on whether
the branch name should be appended to the ``baseURL``
- or the branch is a mercurial named branch and can be
+ or the branch is a Mercurial named branch and can be
found within the ``repourl``.
``clobberOnBranchChange``
@@ -1219,15 +1219,15 @@ The ``Git`` step takes the following arguments:
``submodules``
(optional): when initializing/updating a Git repository, this decides whether
- or not buildbot should consider git submodules. Default: ``False``.
+ or not buildbot should consider Git submodules. Default: ``False``.
``reference``
(optional): use the specified string as a path to a reference
repository on the local machine. Git will try to grab objects from
this path first instead of the main repository, if they exist.
``shallow``
- (optional): instructs git to attempt shallow clones (``--depth 1``). If the
+ (optional): instructs Git to attempt shallow clones (``--depth 1``). If the
user/scheduler asks for a specific revision, this parameter is ignored.
``progress``
@@ -1294,7 +1294,7 @@ The Repo step takes the following arguments:
(optional, defaults to ``None``): the repo tarball used for
fast bootstrap. If not present the tarball will be created
automatically after first sync. It is a copy of the ``.repo``
- directory which contains all the git objects. This feature helps
+ directory which contains all the Git objects. This feature helps
to minimize network usage on very big projects.
``jobs``
@@ -1640,7 +1640,7 @@ false-positives. To use a different regexp, provide a
f.addStep(Compile(command=["make", "test"],
warningPattern="^Warning: "))
-The ``warningPattern=`` can also be a pre-compiled python regexp
+The ``warningPattern=`` can also be a pre-compiled Python regexp
object: this makes it possible to add flags like ``re.I`` (to use
case-insensitive matching).
@@ -2233,7 +2233,7 @@ found in the shell search path. It can be overridden with the ``trial``
parameter. This is useful for Twisted's own unittests, which want to use the
copy of bin/trial that comes with the sources.
-To influence the version of python being used for the tests, or to add flags to
+To influence the version of Python being used for the tests, or to add flags to
the command, set the ``python`` parameter. This can be a string (like
``python2.2``) or a list (like ``['python2.3', '-Wall']``).
View
24 master/docs/manual/cfg-changesources.rst
@@ -85,9 +85,9 @@ Git
:file:`contrib/github_buildbot.py`, which listens for notifications
from GitHub)
* :bb:chsrc:`Change Hooks` in WebStatus
- * github change hook (specifically designed for GitHub notifications,
+ * GitHub change hook (specifically designed for GitHub notifications,
but requiring a publicly-accessible WebStatus)
- * :bb:chsrc:`GitPoller` (polling a remote git repository)
+ * :bb:chsrc:`GitPoller` (polling a remote Git repository)
* :bb:chsrc:`GoogleCodeAtomPoller` (polling the
commit feed for a GoogleCode Git repository)
@@ -98,7 +98,7 @@ Repo/Git
Monotone
* :bb:chsrc:`PBChangeSource` (listening for connections from
- :file:`monotone-buildbot.lua`, which is available with monotone)
+ :file:`monotone-buildbot.lua`, which is available with Monotone)
All VC systems can be driven by a :bb:chsrc:`PBChangeSource` and the ``buildbot
sendchange`` tool run from some form of commit script. If you write an email
@@ -487,7 +487,7 @@ The following hooks are useful for sending changes to a :bb:chsrc:`PBChangeSourc
Mercurial Hook
++++++++++++++
-Since Mercurial is written in python, the hook script can invoke
+Since Mercurial is written in Python, the hook script can invoke
Buildbot's :meth:`sendchange` function directly, rather than having to
spawn an external process. This function delivers the same sort of
changes as :command:`buildbot sendchange` and the various hook scripts in
@@ -498,7 +498,7 @@ To set this up, first choose a Mercurial repository that represents
your central `official` source tree. This will be the same
repository that your buildslaves will eventually pull from. Install
Buildbot on the machine that hosts this repository, using the same
-version of python as Mercurial is using (so that the Mercurial hook
+version of Python as Mercurial is using (so that the Mercurial hook
can import code from buildbot). Then add the following to the
:file:`.hg/hgrc` file in that repository, replacing the buildmaster
hostname/portnumber as appropriate for your buildbot:
@@ -618,7 +618,7 @@ Compatibility
As twisted needs to hook some signals, and some web servers
strictly forbid that, the parameter ``fork`` in the
-``[hgbuildbot]`` section will instruct mercurial to fork before
+``[hgbuildbot]`` section will instruct Mercurial to fork before
sending the change request. Then as the created process will be of short
life, it is considered as safe to disable the signal restriction in
the Apache setting like that ``WSGIRestrictSignal Off``. Refer to the
@@ -1021,13 +1021,13 @@ GitPoller
If you cannot take advantage of post-receive hooks as provided by
:file:`contrib/git_buildbot.py` for example, then you can use the :bb:chsrc:`GitPoller`.
-The :bb:chsrc:`GitPoller` periodically fetches from a remote git repository and processes any changes.
+The :bb:chsrc:`GitPoller` periodically fetches from a remote Git repository and processes any changes.
It requires its own working directory for operation.
The default should be adequate, but it can be overridden via the ``workdir`` property.
.. note:: There can only be a single `GitPoller` pointed at any given repository.
-The :bb:chsrc:`GitPoller` requires git-1.7 and later. It accepts the following
+The :bb:chsrc:`GitPoller` requires Git-1.7 and later. It accepts the following
arguments:
``repourl``
@@ -1046,7 +1046,7 @@ arguments:
interval in seconds between polls, default is 10 minutes
``gitbin``
- path to the git binary, defaults to just ``'git'``
+ path to the Git binary, defaults to just ``'git'``
``category``
Set the category to be used for the changes produced by the
@@ -1068,16 +1068,16 @@ arguments:
``encoding``
Set encoding will be used to parse author's name and commit
message. Default encoding is ``'utf-8'``. This will not be
- applied to file names since git will translate non-ascii file
+ applied to file names since Git will translate non-ascii file
names to unreadable escape sequences.
``workdir``
the directory where the poller should keep its local repository.
The default is :samp:`gitpoller_work`.
If this is a relative path, it will be interpreted relative to the master's basedir.
- Multiple git pollers can share the same directory.
+ Multiple Git pollers can share the same directory.
-An configuration for the git poller might look like this::
+An configuration for the Git poller might look like this::
from buildbot.changes.gitpoller import GitPoller
c['change_source'] = GitPoller('git@example.com:foobaz/myrepo.git',
View
2 master/docs/manual/cfg-global.rst
@@ -263,7 +263,7 @@ The available caches are:
``Changes``
the number of change objects to cache in memory.
This should be larger than the number of changes that typically arrive in the span of a few minutes, otherwise your schedulers will be reloading changes from the database every time they run.
- For distributed version control systems, like git or hg, several thousand changes may arrive at once, so setting this parameter to something like 10000 isn't unreasonable.
+ For distributed version control systems, like Git or Hg, several thousand changes may arrive at once, so setting this parameter to something like 10000 isn't unreasonable.
This parameter is the same as the deprecated global parameter :bb:cfg:`changeCacheSize`. Its default value is 10.
View
8 master/docs/manual/cfg-properties.rst
@@ -193,7 +193,7 @@ example above, it replaces an argument to ``echo``. Often, properties need to
be interpolated into strings, instead. The tool for that job is
:ref:`Interpolate`.
-The more common pattern is to use python dictionary-style string interpolation by using the ``%(prop:<propname>)s`` syntax.
+The more common pattern is to use Python dictionary-style string interpolation by using the ``%(prop:<propname>)s`` syntax.
In this form, the property name goes in the parentheses, as above.
A common mistake is to omit the trailing "s", leading to a rather obscure error from Python ("ValueError: unsupported format character"). ::
@@ -262,7 +262,7 @@ Here, ``%s`` is used as a placeholder, and the substitutions (which may themselv
.. note:
- Like python, you can use either positional interpolation *or*
+ Like Python, you can use either positional interpolation *or*
dictionary-style interpolation, not both. Thus you cannot use a string
like ``Interpolate("foo-%(src::revision)s-%s", "branch")``.
@@ -320,7 +320,7 @@ create a tarball with a name like
.. index:: unsupported format character
-The more common pattern is to use python dictionary-style string interpolation
+The more common pattern is to use Python dictionary-style string interpolation
by using the ``%(propname)s`` syntax. In this form, the property name goes in
the parentheses, as above. A common mistake is to omit the trailing "s",
leading to a rather obscure error from Python ("ValueError: unsupported format
@@ -358,7 +358,7 @@ Although these are similar to shell substitutions, no other
substitutions are currently supported, and ``replacement`` in the
above cannot contain more substitutions.
-Note: like python, you can use either positional interpolation *or*
+Note: like Python, you can use either positional interpolation *or*
dictionary-style interpolation, not both. Thus you cannot use a string like
``WithProperties("foo-%(revision)s-%s", "branch")``.
View
6 master/docs/manual/cfg-schedulers.rst
@@ -896,7 +896,7 @@ file is something like::
label="force a make clean", default=False),
StringParameter(name="pull_url",
- label="optionally give a public git pull url:<br>",
+ label="optionally give a public Git pull url:<br>",
default="", size=80)
]
)
@@ -979,7 +979,7 @@ StringParameter
::
StringParameter(name="pull_url",
- label="optionally give a public git pull url:<br>",
+ label="optionally give a public Git pull url:<br>",
default="", size=80)
This parameter type will show a single-line text-entry box, and allow the user
@@ -1017,7 +1017,7 @@ the StringParameter arguments, this type allows:
This class could be subclassed in order to have more customization e.g.
- * developer could send a list of git branches to pull from
+ * developer could send a list of Git branches to pull from
* developer could send a list of gerrit changes to cherry-pick,
View
4 master/docs/manual/cfg-statustargets.rst
@@ -269,7 +269,7 @@ be used to access them.
The console view is still in development. At this moment by
default the view sorts revisions lexically, which can lead to odd
- behavior with non-integer revisions (e.g., git), or with integer
+ behavior with non-integer revisions (e.g., Git), or with integer
revisions of different length (e.g., 999 and 1000). It also has
some issues with displaying multiple braches at the same time. If
you do have multiple branches, you should use the ``branch=``
@@ -702,7 +702,7 @@ submission of an arbitrary change request. Run :command:`post_build_request.py
--help` for more information. The ``base`` dialect must be enabled for this to
work.
-github hook
+GitHub hook
###########
The GitHub hook is simple and takes no options. ::
View
4 master/docs/manual/cmdline.rst
@@ -337,7 +337,7 @@ for each tree you use, so it may be more convenient to use the
``try_topfile`` approach instead.
Other VC systems which work on full projects instead of individual
-directories (darcs, mercurial, git, monotone) do not require
+directories (Darcs, Mercurial, Git, Monotone) do not require
:command:`try` to know the top directory, so the :option:`--try-topfile`
and :option:`--try-topdir` arguments will be ignored.
@@ -792,7 +792,7 @@ command will look for a special directory named :file:`.buildbot`,
starting from the current directory (where the command was run) and
crawling upwards, eventually looking in the user's home directory. It
will look for a file named :file:`options` in this directory, and will
-evaluate it as a python script, looking for certain names to be set.
+evaluate it as a Python script, looking for certain names to be set.
You can just put simple ``name = 'value'`` pairs in this file to
set the options.
View
2 master/docs/manual/concepts.rst
@@ -572,7 +572,7 @@ User Objects
User Objects allow Buildbot to better manage users throughout its various
interactions with users (see :ref:`Change-Sources` and :ref:`Status-Targets`).
The User Objects are stored in the Buildbot database and correlate the various
-attributes that a user might have: irc, git, etc.
+attributes that a user might have: irc, Git, etc.
Changes
+++++++
View
18 master/docs/manual/customization.rst
@@ -11,7 +11,7 @@ This chapter describes some of the more common idioms in advanced Buildbot
configurations.
At the moment, this chapter is an unordered set of suggestions; if you'd like
-to clean it up, fork the project on github and get started!
+to clean it up, fork the project on GitHub and get started!
Programmatic Configuration Generation
-------------------------------------
@@ -275,7 +275,7 @@ there are a number of related sub-projects that all get released in a group.
For example, `Divmod.org <http://Divmod.org>`_ hosts a project named `Nevow` as
well as one named `Quotient`. In a checked-out Nevow tree there is a directory
-named `formless` that contains a python source file named :file:`webform.py`.
+named `formless` that contains a Python source file named :file:`webform.py`.
This repository is accessible via webdav (and thus uses an `http:` scheme)
through the divmod.org hostname. There are many branches in this repository,
and they use a ``({BRANCHNAME})/({PROJECT})`` naming policy.
@@ -632,7 +632,7 @@ stripped completely. This latter option makes it easy to save the
results to a file and run :command:`grep` or whatever against the
output.
-Each :class:`BuildStep` contains a mapping (implemented in a python dictionary)
+Each :class:`BuildStep` contains a mapping (implemented in a Python dictionary)
from :class:`LogFile` name to the actual :class:`LogFile` objects. Status plugins can
get a list of LogFiles to display, for example, a list of HREF links
that, when clicked, provide the full contents of the :class:`LogFile`.
@@ -971,8 +971,8 @@ clause like::
f.addStep(SVN(svnurl="stuff"))
f.addStep(Framboozle())
-Remember that :file:`master.cfg` is secretly just a python program with one
-job: populating the :file:`BuildmasterConfig` dictionary. And python programs
+Remember that :file:`master.cfg` is secretly just a Python program with one
+job: populating the :file:`BuildmasterConfig` dictionary. And Python programs
are allowed to define as many classes as they like. So you can define
classes and use them in the same file, just as long as the class is
defined before some other code tries to use it.
@@ -1019,10 +1019,10 @@ or::
f.addStep(SVN(svnurl="stuff"))
f.addStep(framboozle.Framboozle())
-(check out the python docs for details about how "import" and "from A
+(check out the Python docs for details about how "import" and "from A
import B" work).
-What we've done here is to tell python that every time it handles an
+What we've done here is to tell Python that every time it handles an
"import" statement for some named module, it should look in our
:file:`~/lib/python/` for that module before it looks anywhere else. After our
directories, it will try in a bunch of standard directories too
@@ -1039,9 +1039,9 @@ to start your buildmaster in a slightly weird way, or you have to
modify your environment to set the :envvar:`PYTHONPATH` variable.
-Option 3: Install this code into a standard python library directory
+Option 3: Install this code into a standard Python library directory
-Find out what your python's standard include path is by asking it:
+Find out what your Python's standard include path is by asking it:
.. code-block:: none
View
20 master/docs/manual/installation.rst
@@ -31,7 +31,7 @@ buildslave:
Python: http://www.python.org
- Buildbot requires python-2.5 or later on the master, although Python-2.7 is
+ Buildbot requires Python-2.5 or later on the master, although Python-2.7 is
recommended. The slave run on Python-2.4.
Twisted: http://twistedmatrix.com
@@ -80,13 +80,13 @@ sqlite3: http://www.sqlite.org
pysqlite: http://pypi.python.org/pypi/pysqlite
- The SQLite Python package is required for python-2.5 and earlier (it is already
- included in python-2.5 and later, but the version in python-2.5 has nasty bugs)
+ The SQLite Python package is required for Python-2.5 and earlier (it is already
+ included in Python-2.5 and later, but the version in Python-2.5 has nasty bugs)
simplejson: http://pypi.python.org/pypi/simplejson
- The simplejson package is required for python-2.5 and earlier (it is already
- included as json in python-2.6 and later)
+ The simplejson package is required for Python-2.5 and earlier (it is already
+ included as json in Python-2.6 and later)
Jinja2: http://jinja.pocoo.org/
@@ -144,7 +144,7 @@ and for the slave:
Installation From Tarballs
~~~~~~~~~~~~~~~~~~~~~~~~~~
-Buildbot and Buildslave are installed using the standard python
+Buildbot and Buildslave are installed using the standard Python
`distutils <http://docs.python.org/library/distutils.html>`_ process. For either
component, after unpacking the tarball, the process is:
@@ -176,7 +176,7 @@ when it tries to load the libaries, then something went wrong.
``pydoc buildbot`` is another useful diagnostic tool.
Windows users will find these files in other places. You will need to
-make sure that python can find the libraries, and will probably find
+make sure that Python can find the libraries, and will probably find
it convenient to have :command:`buildbot` on your :envvar:`PATH`.
.. _Installation-in-a-Virtualenv:
@@ -678,7 +678,7 @@ Other Buildslave Configuration
commandline arguments into byte strings in order to pass to the operating
system when spawning new processes.
- The default value is what python's :func:`sys.getfilesystemencoding()` returns, which
+ The default value is what Python's :func:`sys.getfilesystemencoding()` returns, which
on Windows is 'mbcs', on Mac OSX is 'utf-8', and on Unix depends on your locale
settings.
@@ -962,9 +962,9 @@ Cron jobs are typically run with a minimal shell (:file:`/bin/sh`, not
commands. You may want to use explicit paths, because the :envvar:`PATH`
is usually quite short and doesn't include anything set by your
shell's startup scripts (:file:`.profile`, :file:`.bashrc`, etc). If
-you've installed buildbot (or other python libraries) to an unusual
+you've installed buildbot (or other Python libraries) to an unusual
location, you may need to add a :envvar:`PYTHONPATH` specification (note
-that python will do tilde-expansion on :envvar:`PYTHONPATH` elements by
+that Python will do tilde-expansion on :envvar:`PYTHONPATH` elements by
itself). Sometimes it is safer to fully-specify everything:
.. code-block:: none
View
2 master/docs/manual/introduction.rst
@@ -25,7 +25,7 @@ Features:
* run builds on a variety of slave platforms
* arbitrary build process: handles projects using C, Python, whatever
-* minimal host requirements: python and Twisted
+* minimal host requirements: Python and Twisted
* slaves can be behind a firewall if they can still do checkout
* status delivery through web page, email, IRC, other protocols
* track builds in progress, provide estimated completion time
View
4 master/docs/relnotes/0.8.6.rst
@@ -41,7 +41,7 @@ In addition to what's listed below, the 0.8.6p1 release adds the following.
Master
------
-* If you are using the github hook, carefully consider the security
+* If you are using the GitHub hook, carefully consider the security
implications of allowing un-authenticated change requests, which can
potentially build arbitrary code. See :bb:bug:`2186`.
@@ -210,7 +210,7 @@ Details
-------
For a more detailed description of the changes made in this version, see the
-git log itself:
+Git log itself::
git log buildbot-0.8.5..buildbot-0.8.6
View
4 master/docs/relnotes/0.8.7.rst
@@ -37,7 +37,7 @@ Features
* ``IRenderable.getRenderingFor`` can now return a deferred.
-* The mercurial hook now supports multple masters. See :bb:pull:`436`.
+* The Mercurial hook now supports multple masters. See :bb:pull:`436`.
* There's a new poller for Mercurial: :bb:chsrc:`HgPoller`.
@@ -206,7 +206,7 @@ Details
-------
For a more detailed description of the changes made in this version, see the
-git log itself:
+Git log itself::
git log v0.8.6..v0.8.7
View
2 master/docs/relnotes/index.rst
@@ -48,7 +48,7 @@ Details
-------
For a more detailed description of the changes made in this version, see the
-git log itself:
+git log itself::
git log v0.8.7..master
View
8 master/docs/tutorial/firstrun.rst
@@ -32,13 +32,13 @@ systems. (The preferred method would be to install buildbot from packages
of your distribution.)
To make this work, you will need the following installed:
- * python_ and the development packages for it
+ * Python_ and the development packages for it
* virtualenv_
- * git_
+ * Git_
-.. _python: http://www.python.org/
+.. _Python: http://www.python.org/
.. _virtualenv: http://pypi.python.org/pypi/virtualenv/
-.. _git: http://git-scm.com/
+.. _Git: http://git-scm.com/
Preferably, use your package installer to install these.
View
4 master/docs/tutorial/tour.rst
@@ -295,7 +295,7 @@ Insert the following to enable debugging mode with manhole::
from buildbot import manhole
c['manhole'] = manhole.PasswordManhole("tcp:1234:interface=127.0.0.1","admin","passwd")
-After restarting the master, you can ssh into the master and get an interactive python shell::
+After restarting the master, you can ssh into the master and get an interactive Python shell::
ssh -p1234 admin@127.0.0.1
# enter passwd at prompt
@@ -351,7 +351,7 @@ Then run buildbot's try command as follows::
buildbot try --connect=pb --master=127.0.0.1:5555 --username=sampleuser --passwd=samplepass --vc=git
This will do "git diff" for you and send the resulting patch to
-the server for build and test against the latest sources from git.
+the server for build and test against the latest sources from Git.
Now go back to the `waterfall <http://localhost:8010/waterfall>`_
page, click on the runtests link, and scroll down. You should see that

0 comments on commit 67e1507

Please sign in to comment.
Something went wrong with that request. Please try again.