option, for example to standardize on one internet-facing web server, to add

  encryption or special authentication or for other security reasons, to

  provide caching of static files, or to provide load balancing or fail-over.

  Nginx_, Varnish_ and HAProxy_ are often used for this purpose, often in front

  of a ``gearbox serve`` that somehow is wrapped as a service.

The best option depends on what you are familiar with and the requirements for

performance and stability. Also, keep in mind that Kallithea mainly is serving

dynamically generated pages from a relatively slow Python process. Kallithea is

also often used inside organizations with a limited amount of users and thus no

continuous hammering from the internet.

.. note::

   Kallithea, the libraries it uses, and Python itself do in several places use

   simple caching in memory. Caches and memory are not always released in a way

   that is suitable for long-running processes. They might appear to be leaking

   memory. The worker processes should thus regularly be restarted - for

   example after 1000 requests and/or one hour. This can usually be done by the

   web server or the tool used for running it as a system service.

.. _Python: http://www.python.org/

.. _Gunicorn: http://gunicorn.org/

.. _Gevent: http://www.gevent.org/

.. _PyPI: https://pypi.python.org/pypi

.. _Apache httpd: http://httpd.apache.org/

.. _mod_wsgi: https://code.google.com/p/modwsgi/

.. _isapi-wsgi: https://github.com/hexdump42/isapi-wsgi

.. _nginx: http://nginx.org/en/

.. _iis: http://en.wikipedia.org/wiki/Internet_Information_Services

.. _pip: http://en.wikipedia.org/wiki/Pip_%28package_manager%29

.. _WSGI: http://en.wikipedia.org/wiki/Web_Server_Gateway_Interface

.. _HAProxy: http://www.haproxy.org/

.. _Varnish: https://www.varnish-cache.org/

.. _npm: https://www.npmjs.com/

   location will apply to all system users, and that multiple entries for the

   same SSH key will shadow each other.

.. warning:: The handling of SSH access is steered directly by the command

    specified in the ``authorized_keys`` file. There is no interaction with the

    web UI.  Once SSH access is correctly configured and enabled, it will work

    regardless of whether the Kallithea web process is actually running. Hence,

    if you want to perform repository or server maintenance and want to fully

    disable all access to the repositories, disable SSH access by setting

    ``ssh_enabled = false`` in the correct ``.ini`` file (i.e. the ``.ini`` file

    specified in the ``authorized_keys`` file.)

The ``authorized_keys`` file can be updated manually with ``kallithea-cli

ssh-update-authorized-keys -c my.ini``. This command is not needed in normal

operation but is for example useful after changing SSH-related settings in the

``.ini`` file or renaming that file. (The path to the ``.ini`` file is used in

the generated ``authorized_keys`` file).

Setting up Whoosh full text search

----------------------------------

Kallithea provides full text search of repositories using `Whoosh`__.

For an incremental index build, run::

    kallithea-cli index-create -c my.ini

For a full index rebuild, run::

    kallithea-cli index-create -c my.ini --full

The ``--repo-location`` option allows the location of the repositories to be overridden;

usually, the location is retrieved from the Kallithea database.

The ``--index-only`` option can be used to limit the indexed repositories to a comma-separated list::

    kallithea-cli index-create -c my.ini --index-only=vcs,kallithea

To keep your index up-to-date it is necessary to do periodic index builds;

for this, it is recommended to use a crontab entry. Example::

    0  3  *  *  *  /path/to/virtualenv/bin/kallithea-cli index-create -c /path/to/kallithea/my.ini

When using incremental mode (the default), Whoosh will check the last

modification date of each file and add it to be reindexed if a newer file is

available. The indexing daemon checks for any removed files and removes them

- ``pull_request_comment``: a comment was given on a pull request

- ``cs_comment``: a comment was given on a changeset

- ``registration``: a new user was registered

- ``message``: another type of email

Error emails

------------

When an exception occurs in Kallithea -- and unless interactive debugging is

enabled using ``set debug = true`` in the ``[app:main]`` section of the

configuration file -- an email with exception details is sent by backlash_

to the addresses specified in ``email_to`` in the configuration file.

Recipients will see these emails originating from the sender specified in the

``error_email_from`` setting in the configuration file. This setting can either

contain only an email address, like `kallithea-noreply@example.com`, or both

a name and an address in the following format: `Kallithea Errors

<kallithea-noreply@example.com>`.

References

----------

.. _backlash: https://github.com/TurboGears/backlash

echo "Shortlog for inclusion in the release announcement"

scripts/shortlog.py "only('.', branch('stable') & tagged() & public() & not '.')"

cat - << EOT

Now, make sure

* all tests are passing

* release note is ready

* announcement is ready

* source has been pushed to https://kallithea-scm.org/repos/kallithea

EOT

echo "Verify current revision is tagged for $version"

hg log -r "'$version'&." | grep .

echo -n "Enter \"pypi\" to upload Kallithea $version to pypi: "

read answer

[ "$answer" = "pypi" ]

echo "Rebuild readthedocs for docs.kallithea-scm.org"

xdg-open https://readthedocs.org/projects/kallithea/

curl -X POST http://readthedocs.org/build/kallithea

xdg-open https://readthedocs.org/projects/kallithea/builds

twine upload dist/*

xdg-open https://pypi.python.org/pypi/Kallithea