kallithea Changeset - 570a4e40f0bb

Changeset - 570a4e40f0bb

Parent rev.

Child rev.

[Not reviewed]

default

0 2 0

Andrew Shadura - 11 years ago 2015-02-25 14:06:27
andrew@shadura.me

docs: improve issue tracker integration docs

2 files changed with 23 insertions and 7 deletions:

docs/changelog.rst

+chmod

docs/setup.rst

0 comments (0 inline, 0 general)

docs/changelog.rst

➞

Show inline comments

modified file chmod 100755 => 100644

docs/setup.rst

➞

Show inline comments

@@ modified file chmod 100755 => 100644 @@
@@ @@ -402,107 +402,123 @@ In a proxy pass-through authentication s @@
 from the ``X-Forwarded-User`` request header, which should be configured to be
 sent by the reverse-proxy server.
 After setting up your proxy solution (see `Apache virtual host reverse proxy example`_,
 `Apache as subdirectory`_ or `Nginx virtual host example`_), you'd need to
 configure the authentication and add the username in a request header named
 ``X-Forwarded-User``.
 For example, the following config section for Apache sets a subdirectory in a
 reverse-proxy setup with basic auth::
     <Location /<someprefix> >
       ProxyPass http://127.0.0.1:5000/<someprefix>
       ProxyPassReverse http://127.0.0.1:5000/<someprefix>
       SetEnvIf X-Url-Scheme https HTTPS=1
       AuthType Basic
       AuthName "Kallithea authentication"
       AuthUserFile /home/web/kallithea/.htpasswd
       require valid-user
       RequestHeader unset X-Forwarded-User
       RewriteEngine On
       RewriteCond %{LA-U:REMOTE_USER} (.+)
       RewriteRule .* - [E=RU:%1]
       RequestHeader set X-Forwarded-User %{RU}e
     </Location>
 .. note::
    If you enable proxy pass-through authentication, make sure your server is
    only accessible through the proxy. Otherwise, any client would be able to
    forge the authentication header and could effectively become authenticated
    using any account of their liking.
 Integration with Issue trackers
 -------------------------------
 Kallithea provides a simple integration with issue trackers. It's possible
 to define a regular expression that will fetch issue id stored in commit
 messages and replace that with an url to this issue. To enable this simply
 uncomment following variables in the ini file::
     issue_pat = (?:^#|\s#)(\w+)
     issue_server_link = https://myissueserver.com/{repo}/issue/{id}
     issue_prefix = #
 `issue_pat` is the regular expression that will fetch issues from commit messages.
 Default regex will match issues in format of #<number> eg. #300.
 `issue_pat` is the regular expression describing which strings in
 commit messages will be treated as issue references. A match group in
 parentheses should be used to specify the actual issue id.
 The default expression matches issues in the format '#<number>', e.g. '#300'.
 Matched issues will be replace with the link specified as `issue_server_link`
 {id} will be replaced with issue id, and {repo} with repository name.
 Since the # is striped `issue_prefix` is added as a prefix to url.
 `issue_prefix` can be something different than # if you pass
 ISSUE- as issue prefix this will generate an url in format::
 Matched issues are replaced with the link specified as `issue_server_link`
 {id} is replaced with issue id, and {repo} with repository name.
 Since the # is stripped away, `issue_prefix` is prepended to the link text.
 `issue_prefix` doesn't necessarily need to be #: if you set issue
 prefix to ISSUE- this will generate a URL in format::
   <a href="https://myissueserver.com/example_repo/issue/300">ISSUE-300</a>
 If needed, more than one pattern can be specified by appending a unique suffix to
 the variables. For example::
     issue_pat_wiki = (?:wiki-)(.+)
     issue_server_link_wiki = https://mywiki.com/{id}
     issue_prefix_wiki = WIKI-
 With these settings, wiki pages can be referenced as wiki-some-id, and every
 such reference will be transformed into::
   <a href="https://mywiki.com/some-id">WIKI-some-id</a>
 Hook management
 ---------------
 Hooks can be managed in similar way to this used in .hgrc files.
 To access hooks setting click `advanced setup` on Hooks section of Mercurial
 Settings in Admin.
 There are 4 built in hooks that cannot be changed (only enable/disable by
 checkboxes on previos section).
 To add another custom hook simply fill in first section with
 <name>.<hook_type> and the second one with hook path. Example hooks
 can be found at *kallithea.lib.hooks*.
 Changing default encoding
 -------------------------
 By default Kallithea uses utf8 encoding, starting from 1.3 series this
 can be changed, simply edit default_encoding in .ini file to desired one.
 This affects many parts in Kallithea including committers names, filenames,
 encoding of commit messages. In addition Kallithea can detect if `chardet`
 library is installed. If `chardet` is detected Kallithea will fallback to it
 when there are encode/decode errors.
 Setting Up Celery
 -----------------
 Since version 1.1 celery is configured by the Kallithea ini configuration files.
 Simply set use_celery=true in the ini file then add / change the configuration
 variables inside the ini file.
 Remember that the ini files use the format with '.' not with '_' like celery.
 So for example setting `BROKER_HOST` in celery means setting `broker.host` in
 the config file.
 In order to start using celery run::
  paster celeryd <configfile.ini>
 .. note::
    Make sure you run this command from the same virtualenv, and with the same
    user that Kallithea runs.
 HTTPS support
 -------------

0 comments (0 inline, 0 general)