Files @ d6d3cb5991e2
Branch filter:

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

d6d3cb5991e2 1.2 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>.
.. _debugging:

===================
Debugging Kallithea
===================

If you encounter problems with Kallithea, here are some instructions
on how to debug them.

.. note:: First make sure you're using the latest version available.


Enable detailed debug
---------------------

Kallithea uses the standard Python ``logging`` module to log its output.
By default only loggers with ``INFO`` level are displayed. To enable full output
change ``level = DEBUG`` for all logging handlers in the currently used .ini file.
This change will allow you to see much more detailed output in the log file or
console. This generally helps a lot to track issues.


Enable interactive debug mode
-----------------------------

To enable interactive debug mode simply comment out ``set debug = false`` in
the .ini file. This will trigger an interactive debugger each time
there is an error in the browser, or send a http link if an error occurred in the backend. This
is a great tool for fast debugging as you get a handy Python console right
in the web view.

.. warning:: NEVER ENABLE THIS ON PRODUCTION! The interactive console
             can be a serious security threat to your system.