###################################################################################

###################################################################################

## Kallithea config file generated with kallithea-cli                            ##

##                                                                               ##

## The %(here)s variable will generally be replaced with the parent directory of ##

## this file. Other use of % must be escaped as %% .                             ##

###################################################################################

###################################################################################

[DEFAULT]

################################################################################

## Email settings                                                             ##

##                                                                            ##

## Refer to the documentation ("Email settings") for more details.            ##

##                                                                            ##

## It is recommended to use a valid sender address that passes access         ##

## validation and spam filtering in mail servers.                             ##

################################################################################

## 'From' header for application emails. You can optionally add a name.

## Default:

#app_email_from = Kallithea

## Examples:

#app_email_from = Kallithea <kallithea-noreply@example.com>

#app_email_from = kallithea-noreply@example.com

## Subject prefix for application emails.

## A space between this prefix and the real subject is automatically added.

## Default:

#email_prefix =

## Example:

#email_prefix = [Kallithea]

## Recipients for error emails and fallback recipients of application mails.

## Multiple addresses can be specified, comma-separated.

## Only addresses are allowed, do not add any name part.

## Default:

#email_to =

## Examples:

#email_to = admin@example.com

#email_to = admin@example.com,another_admin@example.com

email_to =

## 'From' header for error emails. You can optionally add a name.

## Default: (none)

## Examples:

#error_email_from = Kallithea Errors <kallithea-noreply@example.com>

#error_email_from = kallithea_errors@example.com

error_email_from =

## SMTP server settings

## If specifying credentials, make sure to use secure connections.

## Default: Send unencrypted unauthenticated mails to the specified smtp_server.

## For "SSL", use smtp_use_ssl = true and smtp_port = 465.

## For "STARTTLS", use smtp_use_tls = true and smtp_port = 587.

smtp_server =

smtp_username =

smtp_password =

smtp_port =

smtp_use_ssl = false

smtp_use_tls = false

## Entry point for 'gearbox serve'

[server:main]

#host = 127.0.0.1

host = 0.0.0.0

port = 5000

## Gearbox serve uses the Waitress web server ##

use = egg:waitress#main

## avoid multi threading

threads = 1

## allow push of repos bigger than the default of 1 GB

max_request_body_size = 107374182400

## use poll instead of select, fixes fd limits, may not work on old

## windows systems.

#asyncore_use_poll = True

## middleware for hosting the WSGI application under a URL prefix

#[filter:proxy-prefix]

#use = egg:PasteDeploy#prefix

#prefix = /<your-prefix>

[app:main]

use = egg:kallithea

## enable proxy prefix middleware

#filter-with = proxy-prefix

full_stack = true

static_files = true

## Internationalization (see setup documentation for details)

## By default, the languages requested by the browser are used if available, with English as default.

## Set i18n.enabled=false to disable automatic language choice.

#i18n.enabled = true

## To Force a language, set i18n.enabled=false and specify the language in i18n.lang.

## Valid values are the names of subdirectories in kallithea/i18n with a LC_MESSAGES/kallithea.mo

#i18n.lang = en

cache_dir = %(here)s/data

index_dir = %(here)s/data/index

## uncomment and set this path to use archive download cache

archive_cache_dir = %(here)s/data/tarballcache

## change this to unique ID for security

#app_instance_uuid = VERY-SECRET

app_instance_uuid = development-not-secret

## cut off limit for large diffs (size in bytes)

cut_off_limit = 256000

## WSGI environment variable to get the IP address of the client (default REMOTE_ADDR)

#remote_addr_variable = HTTP_X_FORWARDED_FOR

## always pretend the client connected using HTTPS (default false)

#force_https = true

## use Strict-Transport-Security headers (default false)

#use_htsts = true

## number of commits stats will parse on each iteration

commit_parse_limit = 25

## Path to Python executable to be used for git hooks.

## This value will be written inside the git hook scripts as the text

## after '#!' (shebang). When empty or not defined, the value of

## 'sys.executable' at the time of installation of the git hooks is

## used, which is correct in many cases but for example not when using uwsgi.

## If you change this setting, you should reinstall the Git hooks via

## Admin > Settings > Remap and Rescan.

#git_hook_interpreter = /srv/kallithea/venv/bin/python3

## path to git executable

git_path = git

## git rev filter option, --all is the default filter, if you need to

## hide all refs in changelog switch this to --branches --tags

#git_rev_filter = --branches --tags

## RSS feed options

rss_cut_off_limit = 256000

rss_items_per_page = 10

rss_include_diff = false

## options for showing and identifying changesets

show_sha_length = 12

show_revision_number = false

## Canonical URL to use when creating full URLs in UI and texts.

## Useful when the site is available under different names or protocols.

## Defaults to what is provided in the WSGI environment.

#canonical_url = https://kallithea.example.com/repos

## gist URL alias, used to create nicer urls for gist. This should be an

## url that does rewrites to _admin/gists/<gistid>.

## example: http://gist.example.com/{gistid}. Empty means use the internal

## Kallithea url, ie. http[s]://kallithea.example.com/_admin/gists/<gistid>

gist_alias_url =

## default encoding used to convert from and to unicode

## can be also a comma separated list of encoding in case of mixed encodings

default_encoding = utf-8

## Set Mercurial encoding, similar to setting HGENCODING before launching Kallithea

hgencoding = utf-8

## issue tracker for Kallithea (leave blank to disable, absent for default)

#bugtracker = https://bitbucket.org/conservancy/kallithea/issues

## issue tracking mapping for commit messages, comments, PR descriptions, ...

## Refer to the documentation ("Integration with issue trackers") for more details.

## regular expression to match issue references

## This pattern may/should contain parenthesized groups, that can

## be referred to in issue_server_link or issue_sub using Python backreferences

## (e.g. \1, \2, ...). You can also create named groups with '(?P<groupname>)'.

## To require mandatory whitespace before the issue pattern, use:

## (?:^|(?<=\s)) before the actual pattern, and for mandatory whitespace

## behind the issue pattern, use (?:$|(?=\s)) after the actual pattern.

issue_pat = #(\d+)

## server url to the issue

## This pattern may/should contain backreferences to parenthesized groups in issue_pat.

## A backreference can be \1, \2, ... or \g<groupname> if you specified a named group

## called 'groupname' in issue_pat.

## The special token {repo} is replaced with the full repository name

## including repository groups, while {repo_name} is replaced with just

## the name of the repository.

issue_server_link = https://issues.example.com/{repo}/issue/\1

## substitution pattern to use as the link text

## If issue_sub is empty, the text matched by issue_pat is retained verbatim

## for the link text. Otherwise, the link text is that of issue_sub, with any

## backreferences to groups in issue_pat replaced.

issue_sub =

## issue_pat, issue_server_link and issue_sub can have suffixes to specify

## multiple patterns, to other issues server, wiki or others

## below an example how to create a wiki pattern

## wiki-some-id -> https://wiki.example.com/some-id

#issue_pat_wiki = wiki-(\S+)

#issue_server_link_wiki = https://wiki.example.com/\1

#issue_sub_wiki = WIKI-\1

## alternative return HTTP header for failed authentication. Default HTTP

## response is 401 HTTPUnauthorized. Currently Mercurial clients have trouble with

## handling that. Set this variable to 403 to return HTTPForbidden

auth_ret_code =

## allows to change the repository location in settings page

allow_repo_location_change = True

## allows to setup custom hooks in settings page

allow_custom_hooks_settings = True

## extra extensions for indexing, space separated and without the leading '.'.

#index.extensions =

#    gemfile

#    lock

## extra filenames for indexing, space separated

#index.filenames =

#    .dockerignore

#    .editorconfig

#    INSTALL

#    CHANGELOG

####################################

##            SSH CONFIG          ##

####################################

## SSH is disabled by default, until an Administrator decides to enable it.

ssh_enabled = false

## File where users' SSH keys will be stored *if* ssh_enabled is true.

#ssh_authorized_keys = /home/kallithea/.ssh/authorized_keys

## Path to be used in ssh_authorized_keys file to invoke kallithea-cli with ssh-serve.

#kallithea_cli_path = /srv/kallithea/venv/bin/kallithea-cli

## Locale to be used in the ssh-serve command.

## This is needed because an SSH client may try to use its own locale

## settings, which may not be available on the server.

## See `locale -a` for valid values on this system.

#ssh_locale = C.UTF-8

####################################

##         CELERY CONFIG          ##

####################################

## Note: Celery doesn't support Windows.

use_celery = false

## Celery config settings from https://docs.celeryproject.org/en/4.4.0/userguide/configuration.html prefixed with 'celery.'.

## Example: use the message queue on the local virtual host 'kallitheavhost' as the RabbitMQ user 'kallithea':

celery.broker_url = amqp://kallithea:thepassword@localhost:5672/kallitheavhost

celery.worker_concurrency = 2

celery.worker_max_tasks_per_child = 100

####################################

##          BEAKER CACHE          ##

####################################

beaker.cache.data_dir = %(here)s/data/cache/data

beaker.cache.lock_dir = %(here)s/data/cache/lock

beaker.cache.regions = long_term,long_term_file

beaker.cache.long_term.type = memory

beaker.cache.long_term.expire = 36000

beaker.cache.long_term.key_length = 256

beaker.cache.long_term_file.type = file

beaker.cache.long_term_file.expire = 604800

beaker.cache.long_term_file.key_length = 256

####################################

##        BEAKER SESSION          ##

####################################

## Name of session cookie. Should be unique for a given host and path, even when running

## on different ports. Otherwise, cookie sessions will be shared and messed up.

session.key = kallithea

## Sessions should always only be accessible by the browser, not directly by JavaScript.

session.httponly = true

## Session lifetime. 2592000 seconds is 30 days.

session.timeout = 2592000

## Server secret used with HMAC to ensure integrity of cookies.

#session.secret = VERY-SECRET

session.secret = development-not-secret

## Further, encrypt the data with AES.

#session.encrypt_key = <key_for_encryption>

#session.validate_key = <validation_key>

## Type of storage used for the session, current types are

## dbm, file, memcached, database, and memory.

## File system storage of session data. (default)

#session.type = file

## Cookie only, store all session data inside the cookie. Requires secure secrets.

#session.type = cookie

## Database storage of session data.

#session.type = ext:database

#session.sa.url = postgresql://postgres:qwe@localhost/kallithea

#session.table_name = db_session

####################################

##        ERROR HANDLING          ##

####################################

## Show a nice error page for application HTTP errors and exceptions (default true)

#errorpage.enabled = true

## Enable Backlash client-side interactive debugger (default false)

## WARNING: *THIS MUST BE false IN PRODUCTION ENVIRONMENTS!!!*

## This debug mode will allow all visitors to execute malicious code.

#debug = false

debug = true

## Enable Backlash server-side error reporting (unless debug mode handles it client-side) (default true)

#trace_errors.enable = true

## Errors will be reported by mail if trace_errors.error_email is set.

## Propagate email settings to ErrorReporter of TurboGears2

## You do not normally need to change these lines

get trace_errors.smtp_server = smtp_server

get trace_errors.smtp_port = smtp_port

get trace_errors.from_address = error_email_from

get trace_errors.error_email = email_to

get trace_errors.smtp_username = smtp_username

get trace_errors.smtp_password = smtp_password

get trace_errors.smtp_use_tls = smtp_use_tls

##################################

##        LOGVIEW CONFIG        ##

##################################

logview.sqlalchemy = #faa

logview.pylons.templating = #bfb

logview.pylons.util = #eee

#########################

##      DB CONFIG      ##

#########################

sqlalchemy.url = sqlite:///%(here)s/kallithea.db?timeout=60

#sqlalchemy.url = postgresql://kallithea:password@localhost/kallithea

#sqlalchemy.url = mysql://kallithea:password@localhost/kallithea?charset=utf8mb4

## Note: the mysql:// prefix should also be used for MariaDB

sqlalchemy.pool_recycle = 3600

################################

##   ALEMBIC CONFIGURATION    ##

################################

[alembic]

script_location = kallithea:alembic

################################

##   LOGGING CONFIGURATION    ##

################################

[loggers]

keys = root, routes, kallithea, sqlalchemy, tg, gearbox, beaker, templates, whoosh_indexer, werkzeug, backlash

[handlers]

keys = console, console_color, console_color_sql, null

[formatters]

keys = generic, color_formatter, color_formatter_sql

#############

## LOGGERS ##

#############

[logger_root]

level = NOTSET

#handlers = console

## For coloring based on log level:

handlers = console_color

[logger_routes]

#level = WARN

level = DEBUG

handlers =

qualname = routes.middleware

## "level = DEBUG" logs the route matched and routing variables.

[logger_beaker]

#level = WARN

level = DEBUG

handlers =

qualname = beaker.container

[logger_templates]

#level = WARN

level = INFO

handlers =

qualname = pylons.templating

[logger_kallithea]

#level = WARN

level = DEBUG

handlers =

qualname = kallithea

[logger_tg]

#level = WARN

level = DEBUG

handlers =

qualname = tg

[logger_gearbox]

#level = WARN

level = DEBUG

handlers =

qualname = gearbox

[logger_sqlalchemy]

level = WARN

handlers =

qualname = sqlalchemy.engine

## For coloring based on log level and pretty printing of SQL:

#level = INFO

#handlers = console_color_sql

#propagate = 0

[logger_whoosh_indexer]

#level = WARN

level = DEBUG

handlers =

qualname = whoosh_indexer

[logger_werkzeug]

level = WARN

handlers =

qualname = werkzeug

[logger_backlash]

level = WARN

handlers =

qualname = backlash

##############

## HANDLERS ##

##############

[handler_console]

class = StreamHandler

args = (sys.stderr,)

formatter = generic

[handler_console_color]

## ANSI color coding based on log level

class = StreamHandler

args = (sys.stderr,)

formatter = color_formatter

[handler_console_color_sql]

## ANSI color coding and pretty printing of SQL statements

class = StreamHandler

args = (sys.stderr,)

formatter = color_formatter_sql

[handler_null]

class = NullHandler

args = ()

################

## FORMATTERS ##

################

[formatter_generic]

format = %(asctime)s.%(msecs)03d %(levelname)-5.5s [%(name)s] %(message)s

datefmt = %Y-%m-%d %H:%M:%S

[formatter_color_formatter]

class = kallithea.lib.colored_formatter.ColorFormatter

format = %(asctime)s.%(msecs)03d %(levelname)-5.5s [%(name)s] %(message)s

datefmt = %Y-%m-%d %H:%M:%S

[formatter_color_formatter_sql]

class = kallithea.lib.colored_formatter.ColorFormatterSql

format = %(asctime)s.%(msecs)03d %(levelname)-5.5s [%(name)s] %(message)s

datefmt = %Y-%m-%d %H:%M:%S

#################

## SSH LOGGING ##

    sudo -u postgres createuser 'kallithea' --pwprompt --createdb

For MariaDB/MySQL, run ``pip install mysqlclient`` to get the ``MySQLdb``

database driver. Make sure the database server is initialized and running. Make

sure you have a database user with password authentication with permissions to

create the database - for example by running::

    echo 'CREATE USER "kallithea"@"localhost" IDENTIFIED BY "password"' | sudo -u mysql mysql

    echo 'GRANT ALL PRIVILEGES ON `kallithea`.* TO "kallithea"@"localhost"' | sudo -u mysql mysql

Check and adjust ``sqlalchemy.url`` in your ``my.ini`` configuration file to use

this database.

Create the database, tables, and initial content by running the following

command::

    kallithea-cli db-create -c my.ini

This will first prompt you for a "root" path. This "root" path is the location

where Kallithea will store all of its repositories on the current machine. This

location must be writable for the running Kallithea application. Next,

``db-create`` will prompt you for a username and password for the initial admin

account it sets up for you.

The ``db-create`` values can also be given on the command line.

Example::

    kallithea-cli db-create -c my.ini --user=nn --password=secret --email=nn@example.com --repos=/srv/repos

The ``db-create`` command will create all needed tables and an

admin account. When choosing a root path you can either use a new

empty location, or a location which already contains existing

repositories. If you choose a location which contains existing

repositories Kallithea will add all of the repositories at the chosen

location to its database.  (Note: make sure you specify the correct

path to the root).

.. note:: It is also possible to use an existing database. For example,

          when using PostgreSQL without granting general createdb privileges to

          the PostgreSQL kallithea user, set ``sqlalchemy.url =

          postgresql://kallithea:password@localhost/kallithea`` and create the

          database like::

              sudo -u postgres createdb 'kallithea' --owner 'kallithea'

              kallithea-cli db-create -c my.ini --reuse

Running

^^^^^^^

You are now ready to use Kallithea. To run it using a gearbox web server,

simply execute::

    gearbox serve -c my.ini

- This command runs the Kallithea server. The web app should be available at

  http://127.0.0.1:5000. The IP address and port is configurable via the

  configuration file created in the previous step.

- Log in to Kallithea using the admin account created when running ``db-create``.

- The default permissions on each repository is read, and the owner is admin.

  Remember to update these if needed.

- In the admin panel you can toggle LDAP, anonymous, and permissions

  settings, as well as edit more advanced options on users and

  repositories.

Internationalization (i18n support)

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

The Kallithea web interface is automatically displayed in the user's preferred

language, as indicated by the browser. Thus, different users may see the

application in different languages. If the requested language is not available

(because the translation file for that language does not yet exist or is

incomplete), English is used.

If you want to disable automatic language detection and instead configure a

fixed language regardless of user preference, set ``i18n.enabled = false`` and

specify another language by setting ``i18n.lang`` in the Kallithea

configuration file.

Using Kallithea with SSH

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

Kallithea supports repository access via SSH key based authentication.

This means:

- repository URLs like ``ssh://kallithea@example.com/name/of/repository``

- all network traffic for both read and write happens over the SSH protocol on

  port 22, without using HTTP/HTTPS nor the Kallithea WSGI application

- encryption and authentication protocols are managed by the system's ``sshd``

  process, with all users using the same Kallithea system user (e.g.

  ``kallithea``) when connecting to the SSH server, but with users' public keys

  in the Kallithea system user's `.ssh/authorized_keys` file granting each user

  sandboxed access to the repositories.

- users and admins can manage SSH public keys in the web UI

- in their SSH client configuration, users can configure how the client should

  control access to their SSH key - without passphrase, with passphrase, and

  optionally with passphrase caching in the local shell session (``ssh-agent``).

  This is standard SSH functionality, not something Kallithea provides or

  interferes with.

- network communication between client and server happens in a bidirectional

  stateful stream, and will in some cases be faster than HTTP/HTTPS with several

  stateless round-trips.

.. note:: At this moment, repository access via SSH has been tested on Unix

    only. Windows users that care about SSH are invited to test it and report

    problems, ideally contributing patches that solve these problems.

Users and admins can upload SSH public keys (e.g. ``.ssh/id_rsa.pub``) through

the web interface. The server's ``.ssh/authorized_keys`` file is automatically

maintained with an entry for each SSH key. Each entry will tell ``sshd`` to run

``kallithea-cli`` with the ``ssh-serve`` sub-command and the right Kallithea user ID

when encountering the corresponding SSH key.

To enable SSH repository access, Kallithea must be configured with the path to

the ``.ssh/authorized_keys`` file for the Kallithea user, and the path to the

``kallithea-cli`` command. Put something like this in the ``.ini`` file::

    ssh_enabled = true

    ssh_authorized_keys = /home/kallithea/.ssh/authorized_keys

    kallithea_cli_path = /srv/kallithea/venv/bin/kallithea-cli

The SSH service must be running, and the Kallithea user account must be active

(not necessarily with password access, but public key access must be enabled),

all file permissions must be set as sshd wants it, and ``authorized_keys`` must

be writeable by the Kallithea user.

.. note:: The ``authorized_keys`` file will be rewritten from scratch on

    each update. If it already exists with other data, Kallithea will not

    overwrite the existing ``authorized_keys``, and the server process will

    instead throw an exception. The system administrator thus cannot ssh

    directly to the Kallithea user but must use su/sudo from another account.

    If ``/home/kallithea/.ssh/`` (the directory of the path specified in the

    ``ssh_authorized_keys`` setting of the ``.ini`` file) does not exist as a

    directory, Kallithea will attempt to create it. If that path exists but is

    *not* a directory, or is not readable-writable-executable by the server

    process, the server process will raise an exception each time it attempts to

    write the ``authorized_keys`` file.

.. note:: It is possible to configure the SSH server to look for authorized

   keys in multiple files, for example reserving ``ssh/authorized_keys`` to be

   used for normal SSH and with Kallithea using

   ``.ssh/authorized_keys_kallithea``. In ``/etc/ssh/sshd_config`` set

   ``AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys_kallithea``

   and restart sshd, and in ``my.ini`` set ``ssh_authorized_keys =

   /home/kallithea/.ssh/authorized_keys_kallithea``. Note that this new

   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`__.

.. __: https://whoosh.readthedocs.io/

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

from index.

If you want to rebuild the index from scratch, you can use the ``-f`` flag as above,

or in the admin panel you can check the "build from scratch" checkbox.

Integration with issue trackers

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

Kallithea provides a simple integration with issue trackers. It's possible

to define a regular expression that will match an issue ID in commit messages,

and have that replaced with a URL to the issue.

This is achieved with following three variables in the ini file::

    issue_pat = #(\d+)

    issue_server_link = https://issues.example.com/{repo}/issue/\1

    issue_sub =

``issue_pat`` is the regular expression describing which strings in

commit messages will be treated as issue references. The expression can/should

have one or more parenthesized groups that can later be referred to in

``issue_server_link`` and ``issue_sub`` (see below). If you prefer, named groups

can be used instead of simple parenthesized groups.

If the pattern should only match if it is preceded by whitespace, add the

following string before the actual pattern: ``(?:^|(?<=\s))``.

If the pattern should only match if it is followed by whitespace, add the

following string after the actual pattern: ``(?:$|(?=\s))``.

These expressions use lookbehind and lookahead assertions of the Python regular

expression module to avoid the whitespace to be part of the actual pattern,

otherwise the link text will also contain that whitespace.

Matched issue references are replaced with the link specified in

``issue_server_link``, in which any backreferences are resolved. Backreferences

can be ``\1``, ``\2``, ... or for named groups ``\g<groupname>``.

The special token ``{repo}`` is replaced with the full repository path

(including repository groups), while token ``{repo_name}`` is replaced with the

repository name (without repository groups).

The link text is determined by ``issue_sub``, which can be a string containing

backreferences to the groups specified in ``issue_pat``. If ``issue_sub`` is

empty, then the text matched by ``issue_pat`` is used verbatim.

The example settings shown above match issues in the format ``#<number>``.

This will cause the text ``#300`` to be transformed into a link:

.. code-block:: html

  <a href="https://issues.example.com/example_repo/issue/300">#300</a>

The following example transforms a text starting with either of 'pullrequest',

'pull request' or 'PR', followed by an optional space, then a pound character

(#) and one or more digits, into a link with the text 'PR #' followed by the

digits::

    issue_pat = (pullrequest|pull request|PR) ?#(\d+)

    issue_server_link = https://issues.example.com/\2

    issue_sub = PR #\2

The following example demonstrates how to require whitespace before the issue

reference in order for it to be recognized, such that the text ``issue#123`` will

not cause a match, but ``issue #123`` will::

    issue_pat = (?:^|(?<=\s))#(\d+)

    issue_server_link = https://issues.example.com/\1

    issue_sub =

If needed, more than one pattern can be specified by appending a unique suffix to

the variables. For example, also demonstrating the use of named groups::

    issue_pat_wiki = wiki-(?P<pagename>\S+)

    issue_server_link_wiki = https://wiki.example.com/\g<pagename>

    issue_sub_wiki = WIKI-\g<pagename>

With these settings, wiki pages can be referenced as wiki-some-id, and every

such reference will be transformed into:

.. code-block:: html

  <a href="https://wiki.example.com/some-id">WIKI-some-id</a>

Refer to the `Python regular expression documentation`_ for more details about

the supported syntax in ``issue_pat``, ``issue_server_link`` and ``issue_sub``.

Hook management

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

Custom Mercurial hooks can be managed in a similar way to that used in ``.hgrc`` files.

To manage hooks, choose *Admin > Settings > Hooks*.

To add another custom hook simply fill in the first textbox with

``<name>.<hook_type>`` and the second with the hook path. Example hooks

can be found in ``kallithea.lib.hooks``.

Kallithea will also use some hooks internally. They cannot be modified, but

some of them can be enabled or disabled in the *VCS* section.

Kallithea does not actively support custom Git hooks, but hooks can be installed

manually in the file system. Kallithea will install and use the

``post-receive`` Git hook internally, but it will then invoke

``post-receive-custom`` if present.

Changing default encoding

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

By default, Kallithea uses UTF-8 encoding.

This is configurable as ``default_encoding`` in the .ini file.

This affects many parts in Kallithea including user names, filenames, and

encoding of commit messages. In addition Kallithea can detect if the ``chardet``

library is installed. If ``chardet`` is detected Kallithea will fallback to it

when there are encode/decode errors.

The Mercurial encoding is configurable as ``hgencoding``. It is similar to

setting the ``HGENCODING`` environment variable, but will override it.

Celery configuration

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

Kallithea can use the distributed task queue system Celery_ to run tasks like

cloning repositories or sending emails.

Kallithea will in most setups work perfectly fine out of the box (without

Celery), executing all tasks in the web server process. Some tasks can however

take some time to run and it can be better to run such tasks asynchronously in

a separate process so the web server can focus on serving web requests.

For installation and configuration of Celery, see the `Celery documentation`_.

Note that Celery requires a message broker service like RabbitMQ_ (recommended)

or Redis_.

The use of Celery is configured in the Kallithea ini configuration file.

To enable it, simply set::

  use_celery = true

and add or change the ``celery.*`` configuration variables.

Configuration settings are prefixed with 'celery.', so for example setting

`broker_url` in Celery means setting `celery.broker_url` in the configuration

file.

To start the Celery process, run::

  kallithea-cli celery-run -c my.ini

Extra options to the Celery worker can be passed after ``--`` - see ``-- -h``

for more info.

.. note::

   Make sure you run this command from the same virtualenv, and with the same

   user that Kallithea runs.

Proxy setups

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

When Kallithea is processing HTTP requests from a user, it will see and use

some of the basic properties of the connection, both at the TCP/IP level and at

the HTTP level. The WSGI server will provide this information to Kallithea in

the "environment".