Files @ d6d3cb5991e2
Branch filter:

Location: kallithea/docs/usage/customization.rst - annotation

d6d3cb5991e2 2.9 KiB text/prs.fallenstein.rst Show Source Show as Raw Download as Raw
mads
tests: stabilize Git committer in test_vcs_operations

Git tries to find out name and email in this order:

1. The author can be set e.g. via the `--author` option of `git commit`.
2. If set, the environment variables GIT_AUTHOR_NAME, GIT_AUTHOR_EMAIL,
GIT_COMMITTER_NAME and GIT_COMMITTER_EMAIL are taken.
3. If set, various (global) config files are considered.
4. Unless disabled by the user.useconfigonly config, the names and emails are
inferred from various system sources such as various fields from /etc/passwd,
/etc/mailname and the environment variable EMAIL.

The author can be provided on the command line (1), but that is not possible
for the committer.

It is not an option to modify Git’s configuration files, so the result of (3)
depends on the system the tests run on, which should be avoided. A follow-up
patch will try to instruct Git to not read the system Git configuration files.

(4) is also system-dependent. On some systems, (4) is disabled in the Git
configuration. If enabled, Git will try to infer the committer name from the
gecko field in /etc/passwd, but will fail if it is empty. The previous code
passed the environment variable EMAIL to provide the corresponding email
address.

By passing the names and emails via (2), we can set the author and committer
name and email uniformly and prevent Git from using the system-dependent ways
(3) and (4). This will replace the use of of EMAIL. The environment variables
were introduced in 2005, so there should be no backwards compatibility
problems.

The tests will specify --author explicitly in the cases where the actual name
matters. We just need default values that can be used for committing when we
don't care.

We set it as static defaults to:
Author: test_regular <test_regular@example.com>
Commit: test_admin <test_admin@example.com>

Based on changes and research by Manuel Jacob <me@manueljacob.de>.
.. _customization:

=============
Customization
=============

There are several ways to customize Kallithea to your needs depending on what
you want to achieve.


HTML/JavaScript/CSS customization
---------------------------------

To customize the look-and-feel of the web interface (for example to add a
company banner or some JavaScript widget or to tweak the CSS style definitions)
you can enter HTML code (possibly with JavaScript and/or CSS) directly via the
*Admin > Settings > Global > HTML/JavaScript customization
block*.


Style sheet customization with Less
-----------------------------------

Kallithea uses `Bootstrap 3`_ and Less_ for its style definitions. If you want
to make some customizations, we recommend to do so by creating a ``theme.less``
file. When you create a file named ``theme.less`` in directory
``kallithea/front-end/`` inside the Kallithea installation, you can use this
file to override the default style. For example, you can use this to override
``@kallithea-theme-main-color``, ``@kallithea-logo-url`` or other `Bootstrap
variables`_.

After creating the ``theme.less`` file, you need to regenerate the CSS files, by
running::

    kallithea-cli front-end-build --no-install-deps

.. _bootstrap 3: https://getbootstrap.com/docs/3.3/
.. _bootstrap variables: https://getbootstrap.com/docs/3.3/customize/#less-variables
.. _less: http://lesscss.org/


Behavioral customization: Kallithea extensions
----------------------------------------------

Some behavioral customization can be done in Python using Kallithea
``extensions``, a custom Python file you can create to extend Kallithea
functionality.

With ``extensions`` it's possible to add additional mappings for Whoosh
indexing and statistics, to add additional code into the push/pull/create/delete
repository hooks (for example to send signals to build bots such as Jenkins) and
even to monkey-patch certain parts of the Kallithea source code (for example
overwrite an entire function, change a global variable, ...).

To generate a skeleton extensions package, run::

    kallithea-cli extensions-create -c my.ini

This will create an ``extensions.py`` file next to the specified ``ini`` file.
You can find more details inside this file.

For compatibility with previous releases of Kallithea, a directory named
``rcextensions`` with a file ``__init__.py`` inside of it can also be used. If
both an ``extensions.py`` file and an ``rcextensions`` directory are found, only
``extensions.py`` will be loaded. Note that the name ``rcextensions`` is
deprecated and support for it will be removed in a future release.


Behavioral customization: code changes
--------------------------------------

As Kallithea is open-source software, you can make any changes you like directly
in the source code.

We encourage you to send generic improvements back to the
community so that Kallithea can become better. See :ref:`contributing` for more
details.