Files
@ 877bcf22bf71
Branch filter:
Location: kallithea/README.rst
877bcf22bf71
9.4 KiB
text/prs.fallenstein.rst
pytest migration: introduce TestControllerPytest
In order to allow tests to benefit from pytest specific functionality, like
fixtures, they can no longer derive from unittest.TestCase. What's more,
while they can derive from any user-defined class, none of the classes
involved (the test class itself nor any of the base classes) can have an
__init__ method.
Converting all tests from unittest-style to pytest-style in one commit is
not realistic. Hence, a more gradual approach is needed.
Most existing test classes derive from TestController, which in turn derives
from BaseTestCase, which derives from unittest.TestCase. Some test classes
derive directly from BaseTestCase.
Supporting both unittest-style and pytest-style from TestController directly
is not possible: pytest-style _cannot_ and unittest-style _must_ derive from
unittest.TestCase. Thus, in any case, an extra level in the class hierarchy
is needed (TestController deriving from Foo and from unittest.TestCase;
pytest-style test classes would then directly derive from Foo).
The requirement that pytest-style test classes cannot have an __init__
method anywhere in the class hierarchy imposes another restriction that
makes it difficult to support both unittest-style and pytest-style test
classes with one class. Any init code needs to be placed in another method
than __init__ and be called explicitly when the test class is initialized.
For unittest-style test classes this would naturally be done with a
setupClass method, but several test classes already use that. Thus, there
would need to be explicit 'super' calls from the test classes. This is
technically possible but not very nice.
A more transparent approach (from the existing test classes point of view),
implemented by this patch, works as follows:
- the implementation of the existing TestController class is now put under
a new class BaseTestController. To accomodate pytest, the __init__ method
is renamed init.
- contrary to the original TestController, BaseTestController does not
derive from BaseTestCase (and neither from unittest.TestCase). Instead,
the 'new' TestController derives both from BaseTestCase, which is
untouched, and from BaseTestController.
- TestController has an __init__ method that calls the base classes'
__init__ methods and the renamed 'init' method of BaseTestController.
- a new class TestControllerPytest is introduced that derives from
BaseTestController but not from BaseTestCase. It uses a pytest fixture to
automatically call the setup functionality previously provided by
BaseTestCase and also calls 'init' on BaseTestController. This means a
little code duplication but is hard to avoid.
The app setup fixture is scoped on the test method, which means that the app
is recreated for every test (unlike for the unittest-style tests where the
app is created per test class). This has the advantage of detecting current
inter-test dependencies and thus improve the health of our test suite. This
in turn is one step closer to allowing parallel test execution.
The unittest-style assert methods (assertEqual, assertIn, ...) do not exist
for pytest-style tests. To avoid having to change all existing test cases
upfront, provide transitional implementations of these methods. The
conversion of the unittest asserts to the pytest/python asserts can happen
gradually over time.
In order to allow tests to benefit from pytest specific functionality, like
fixtures, they can no longer derive from unittest.TestCase. What's more,
while they can derive from any user-defined class, none of the classes
involved (the test class itself nor any of the base classes) can have an
__init__ method.
Converting all tests from unittest-style to pytest-style in one commit is
not realistic. Hence, a more gradual approach is needed.
Most existing test classes derive from TestController, which in turn derives
from BaseTestCase, which derives from unittest.TestCase. Some test classes
derive directly from BaseTestCase.
Supporting both unittest-style and pytest-style from TestController directly
is not possible: pytest-style _cannot_ and unittest-style _must_ derive from
unittest.TestCase. Thus, in any case, an extra level in the class hierarchy
is needed (TestController deriving from Foo and from unittest.TestCase;
pytest-style test classes would then directly derive from Foo).
The requirement that pytest-style test classes cannot have an __init__
method anywhere in the class hierarchy imposes another restriction that
makes it difficult to support both unittest-style and pytest-style test
classes with one class. Any init code needs to be placed in another method
than __init__ and be called explicitly when the test class is initialized.
For unittest-style test classes this would naturally be done with a
setupClass method, but several test classes already use that. Thus, there
would need to be explicit 'super' calls from the test classes. This is
technically possible but not very nice.
A more transparent approach (from the existing test classes point of view),
implemented by this patch, works as follows:
- the implementation of the existing TestController class is now put under
a new class BaseTestController. To accomodate pytest, the __init__ method
is renamed init.
- contrary to the original TestController, BaseTestController does not
derive from BaseTestCase (and neither from unittest.TestCase). Instead,
the 'new' TestController derives both from BaseTestCase, which is
untouched, and from BaseTestController.
- TestController has an __init__ method that calls the base classes'
__init__ methods and the renamed 'init' method of BaseTestController.
- a new class TestControllerPytest is introduced that derives from
BaseTestController but not from BaseTestCase. It uses a pytest fixture to
automatically call the setup functionality previously provided by
BaseTestCase and also calls 'init' on BaseTestController. This means a
little code duplication but is hard to avoid.
The app setup fixture is scoped on the test method, which means that the app
is recreated for every test (unlike for the unittest-style tests where the
app is created per test class). This has the advantage of detecting current
inter-test dependencies and thus improve the health of our test suite. This
in turn is one step closer to allowing parallel test execution.
The unittest-style assert methods (assertEqual, assertIn, ...) do not exist
for pytest-style tests. To avoid having to change all existing test cases
upfront, provide transitional implementations of these methods. The
conversion of the unittest asserts to the pytest/python asserts can happen
gradually over time.
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 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 | ================
Kallithea README
================
About
-----
**Kallithea** is a fast and powerful management tool for Mercurial_ and Git_
with a built-in push/pull server, full text search and code-review. It works on
http/https and has a built in permission/authentication system with the ability
to authenticate via LDAP or ActiveDirectory. Kallithea also provides simple API
so it's easy to integrate with existing external systems.
Kallithea is similar in some respects to GitHub_ or Bitbucket_, however
Kallithea can be run as standalone hosted application on your own server. It is
open-source donationware and focuses more on providing a customised,
self-administered interface for Mercurial_ and Git_ repositories. Kallithea
works on Unix-like systems and Windows, and is powered by the vcs_ library
created by Łukasz Balcerzak and Marcin Kuźmiński to uniformly handle multiple
version control systems.
Kallithea was forked from RhodeCode in July 2014 and has been heavily modified.
Installation
------------
Kallithea requires Python_ 2.x and it is recommended to install it in a
virtualenv_. Official releases of Kallithea can be installed with::
pip install kallithea
The development repository is kept very stable and used in production by the
developers -- you can do the same.
Please visit https://docs.kallithea-scm.org/en/latest/installation.html for
more details.
There is also an experimental `Puppet module`_ for installing and setting up
Kallithea. Currently, only basic functionality is provided, but it is still
enough to get up and running quickly, especially for people without Python
background. See
https://docs.kallithea-scm.org/en/latest/installation_puppet.html for further
information.
Source code
-----------
The latest sources can be obtained from
https://kallithea-scm.org/repos/kallithea.
The issue tracker and a repository mirror can be found at Bitbucket_ on
https://bitbucket.org/conservancy/kallithea.
Kallithea features
------------------
- Has its own middleware to handle Mercurial_ and Git_ protocol requests. Each
request is authenticated and logged together with IP address.
- Built for speed and performance. You can make multiple pulls/pushes
simultaneously. Proven to work with thousands of repositories and users.
- Supports http/https, LDAP, AD, proxy-pass authentication.
- Full permissions (private/read/write/admin) together with IP restrictions for
each repository, additional explicit forking, repositories group and
repository creation permissions.
- User groups for easier permission management.
- Repository groups let you group repos and manage them easier. They come with
permission delegation features, so you can delegate groups management.
- Users can fork other users repos, and compare them at any time.
- Built-in versioned paste functionality (Gist) for sharing code snippets.
- Integrates easily with other systems, with custom created mappers you can
connect it to almost any issue tracker, and with a JSON-RPC API you can make
much more.
- Built-in commit API lets you add, edit and commit files right from Kallithea
web interface using simple editor or upload binary files using simple form.
- Powerful pull request driven review system with inline commenting, changeset
statuses, and notification system.
- Importing and syncing repositories from remote locations for Git_, Mercurial_
and Subversion.
- Mako templates let you customize the look and feel of the application.
- Beautiful diffs, annotations and source code browsing all colored by
pygments. Raw diffs are made in Git-diff format for both VCS systems,
including Git_ binary-patches.
- Mercurial_ and Git_ DAG graphs and Flot-powered graphs with zooming and
statistics to track activity for repositories.
- Admin interface with user/permission management. Admin activity journal, logs
pulls, pushes, forks, registrations and other actions made by all users.
- Server side forks. It is possible to fork a project and modify it freely
without breaking the main repository.
- reST and Markdown README support for repositories.
- Full text search powered by Whoosh on the source files, commit messages, and
file names. Built-in indexing daemons, with optional incremental index build
(no external search servers required all in one application).
- Setup project descriptions/tags and info inside built in DB for easy,
non-filesystem operations.
- Intelligent cache with invalidation after push or project change, provides
high performance and always up to date data.
- RSS/Atom feeds, Gravatar support, downloadable sources as zip/tar/gz.
- Optional async tasks for speed and performance using Celery_.
- Backup scripts can do backup of whole app and send it over scp to desired
location.
- Based on Pylons, SQLAlchemy, SQLite, Whoosh, vcs.
License
-------
**Kallithea** is released under the GPLv3 license. Kallithea is a `Software
Freedom Conservancy`_ project and thus controlled by a non-profit organization.
No commercial entity can take ownership of the project and change the
direction.
Kallithea started out as an effort to make sure the existing GPLv3 codebase
would stay available under a legal license. Kallithea thus has to stay GPLv3
compatible ... but we are also happy it is GPLv3 and happy to keep it that way.
A different license (such as AGPL) could perhaps help attract a different
community with a different mix of Free Software people and companies but we are
happy with the current focus.
Community
---------
**Kallithea** is maintained by its users who contribute the fixes they would
like to see.
Get in touch with the rest of the community:
- Join the mailing list users and developers -- see
http://lists.sfconservancy.org/mailman/listinfo/kallithea-general.
- Use IRC and join #kallithea on FreeNode (irc.freenode.net) or use
http://webchat.freenode.net/?channels=kallithea.
- Follow Kallithea on Twitter, **@KallitheaSCM**.
- Issues can be reported at `issue tracker
<https://bitbucket.org/conservancy/kallithea/issues>`_.
.. note::
Please try to read the documentation before posting any issues,
especially the **troubleshooting section**
Online documentation
--------------------
Online documentation for the current version of Kallithea is available at
https://pythonhosted.org/Kallithea/. Documentation for the current development
version can be found on https://docs.kallithea-scm.org/.
You can also build the documentation locally: go to ``docs/`` and run::
make html
.. note:: You need to have Sphinx_ installed to build the
documentation. If you don't have Sphinx_ installed you can
install it via the command: ``pip install sphinx`` .
Converting from RhodeCode
-------------------------
Currently, you have two options for working with an existing RhodeCode
database:
- keep the database unconverted (intended for testing and evaluation)
- convert the database in a one-time step
Maintaining interoperability
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Interoperability with RhodeCode 2.2.X installations is provided so you don't
have to immediately commit to switching to Kallithea. This option will most
likely go away once the two projects have diverged significantly.
To run Kallithea on a RhodeCode database, run::
echo "BRAND = 'rhodecode'" > kallithea/brand.py
This location will depend on where you installed Kallithea. If you installed
via::
python2 setup.py install
then you will find this location at
``$VIRTUAL_ENV/lib/python2.7/site-packages/Kallithea-0.1-py2.7.egg/kallithea``.
One-time conversion
^^^^^^^^^^^^^^^^^^^
Alternatively, if you would like to convert the database for good, you can use
a helper script provided by Kallithea. This script will operate directly on the
database, using the database string you can find in your ``production.ini`` (or
``development.ini``) file. For example, if using SQLite::
cd /path/to/kallithea
cp /path/to/rhodecode/rhodecode.db kallithea.db
pip install sqlalchemy-migrate
python2 kallithea/bin/rebranddb.py sqlite:///kallithea.db
.. Note::
If you started out using the branding interoperability approach mentioned
above, watch out for stray brand.pyc after removing brand.py.
Git hooks
^^^^^^^^^
After switching to Kallithea, it will be necessary to update the Git_ hooks in
your repositories. If not, the Git_ hooks from RhodeCode will still be called,
which will cause ``git push`` to fail every time.
If you do not have any custom Git_ hooks deployed, perform the following steps
(this may take some time depending on the number and size of repositories you
have):
1. Log-in as an administrator.
2. Open page *Admin > Settings > Remap and Rescan*.
3. Turn on the option **Install Git Hooks**.
4. Turn on the option **Overwrite existing Git hooks**.
5. Click on the button **Rescan Repositories**.
If you do have custom hooks, you will need to merge those changes manually. In
order to get sample hooks from Kallithea, the easiest way is to create a new Git_
repository, and have a look at the hooks deployed there.
.. _virtualenv: http://pypi.python.org/pypi/virtualenv
.. _Python: http://www.python.org/
.. _Sphinx: http://sphinx.pocoo.org/
.. _Mercurial: http://mercurial.selenic.com/
.. _Bitbucket: http://bitbucket.org/
.. _GitHub: http://github.com/
.. _Subversion: http://subversion.tigris.org/
.. _Git: http://git-scm.com/
.. _Celery: http://celeryproject.org/
.. _vcs: http://pypi.python.org/pypi/vcs
.. _Software Freedom Conservancy: http://sfconservancy.org/
.. _Puppet module: https://forge.puppetlabs.com/rauch/kallithea
|