Anton Shestakov <av6@dwimlabs.net>, Sat, 22 Jul 2017 12:55:25 +0800
viewer: don't wrap words in check title, it's short and contains special chars
.. image:: https://candolint.dwimlabs.net/bitbucket.org/av6/candolint/status.svg
:target: https://candolint.dwimlabs.net/bitbucket.org/av6/candolint
- checker.py - command line tool for running a single check
- incoming.py - command line tool for parsing a single check result
- viewer.py - web interface for looking at projects and check results
- hooks-queue.py - web service for handling events from code hosting sites
- poller-queue.py - long-lived HTTP client for polling changes
instances (because they don't have defined events API)
- incoming-queue.py - long-lived process for receiving and parsing check
- worker-queue.py - long-lived worker process for running checks on events
- run-tests.py - test runner, see bitbucket-pipelines.yml for some useful
Here's an example similar to
*candolint.yml* of this project itself:
# bootstrapping data, optional url: https://bitbucket.org/av6/candolint # linter config, required flags: ['--extract', 'always'] This is the two most basic things needed to check out project source code: its
If you use push hooks or polling, this data is already present in the payload.
You only need to put it in
*projects/<name>.yml* file on the worker if you want
to run checks manually (e.g. for testing).
This is the list of linters to run on project source code. Each item only
- ``name``: determines what configuration file from
*linters/\*.yml* will be
used (often named after the actual executable)
- ``include``: a sequence of file patterns for checking
Optional parameters include:
- ``vars``: variables used for installing and running linters (e.g.
- ``codes``: allowed exit codes (by default
``0`` and
``1`` are allowed); note
that this is only for the actual checking, so if
*linter --version* exits
with code
``1``, it's considered a failure
- ``exclude``: a sequence of file patterns to exclude from checks
- ``flags``: additional command line flags passed to the linter (before passing
- ``post_flags``: like
``flags``, but passed after file path
The exact base command executed for each linter is specified in
*linters/\*.yml* and cannot be modified in project configuration file, see the
Base linter configuration ========================= Every linter needs to be configured via
*linters/\*.yml* file. Some files are
already there, they are used to check various projects, including this one
itself. Here's what they look like:
- ['virtualenv', '--python=python%(python_version)s', '../venv%(python_version)s'] - ['../venv%(python_version)s/bin/pip', 'install', 'flake8', 'pep8-naming'] exec: ['../venv%(python_version)s/bin/flake8'] - ``exec``: a list of strings that will be fed to Python's
``subprocess.Popen`` - ``version``: a list of strings that will be used as command line flags for
testing that this linter works after installation
- ``setup``: a list of commands (as lists of strings), each will be executed
consecutively to install this linter
- ``vars``: default values for variables, these can be tweaked in project
- url: https://hg.prosody.im/0.10 poll: https://hg.prosody.im/0.10/json-branches - url: https://github.com/kaitai-io/kaitai_struct_python_runtime poll: https://api.github.com/repos/kaitai-io/kaitai_struct_python_runtime/branches