31 марта 2012 г. Django Git Hooks PEP PEP8 Python CI

Python и Git. Автоматическая проверка кода требованиям спецификации

Многие команды делают Code Review, другие больше сосредотачиваются над Design Review, а многие не делают и вовсе, но статья не о том зачем это нужно, а о том, как частично автоматизировать процесс Code Review. Для своих проектов я решил съэкономить немного времени и человеческих ресурсов, и использовать автоматизированную проверку кода проекта на соответствие PEP 8, а также качества кода (pyflakes) и качество сообщений в Git. Полноценный Code Review при этом делать всёравно нужно, но уже в меньших объемах, а иногда и вовсе можно им пренебречь.

Итак, для работы нам понадобится установить pep8, pyflakes, а также отредактировать на рабочих станциях разработчиков хуки для Git: "pre-commit" и "commit-msg".

Репозиторий тут

Серверные хуки специально не используются, так как уже будет произведен коммит и разработчику придется откатываться и т.д., что совсем не экономит время разработчика.

Установка

Установим зависимости:

sudo apt-get install pyflakes pep8

Установим хуки:

cd ~/work
git clone git://github.com/adw0rd/pre-code-review.git pre-code-review
ln -s /home/<username>/work/pre-code-review/pre-commit.py /home/<username>/work/<project>/.git/hooks/pre-commit
ln -s /home/<username>/work/pre-code-review/commit-msg.py /home/<username>/work/<project>/.git/hooks/commit-msg
chmod +x /home/<username>/work/<project>/.git/hooks/pre-commit
chmod +x /home/<username>/work/<project>/.git/hooks/commit-msg

Код для хука "pre-commit.py" повзаимствован отсюда и впоследствии доработан. В будующем планировалось добавить туда проверку докстрингов (процентное соотношение документации к коду, либо какие-либо другие метрики) и запуск тестов (но это сомнительно, так как скажется на производительности выполнения коммитов).

Для таких тяжелых операций как тесты есть удобный инструмент - Continuous Integraton (CI), такие как Hudson, Jenkins (django-jenkins), CruiseControl и Atlassian Bamboo. Также, рекомендую ознакомится с продуктом для Code Review - Atlassian Crucible.

Примеры

Пример проверки кода:

$ git commit -m "Something I"
*********************************
***** CODE REVIEW IS FAILED *****
*********************************
Check files: <project>/<app>/views.py, <project>/common/context_processors.py, <project>/common/decorators.py,
<project>/settings.py, <project>/<app>/models.py, <project>/urls.py
pep8:
./<project>/urls.py:14:19: E241 multiple spaces after ','
./<project>/<app>/models.py:18:1: E302 expected 2 blank lines, found 1
pyflakes:
./<project>/urls.py:3: 'include' imported but unused
./<project>/urls.py:4: undefined name 'User'

Хук "pre-commit" проверяет только staged изменения (поэтому после каждого фикса вам придется делать git-add), для того чтобы проверять весь индекс сразу нужно использовать "--debug":

$ .git/hooks/pre-commit --debug

Пример проверки сообщения коммита:

$ git commit -m "Something II"
**********************************
***** CHECK COMMIT IS FAILED *****
**********************************
> check_task_tracking_identificator:
>> Wrong Issue ID! Use format: [{project_id}-{issue_number}], example: [PROJ-1027]

Если добавить к команде git-commit опцию "--no-verify", то вы сможете пропустить проверку хуков.

-n, --no-verify
    This option bypasses the pre-commit and commit-msg hooks. See also githooks(5).

Такого вида контроль повышает качества кода на входе в репозиторий, разработчики оставляют меньше граблей в коде и т.д. Вообщем это минимум, который нужен для повышения качества вашего проекта.

Комментарии

Также можно определить хук "prepare-commit-msg", который будет на основании имени ветки (например "task_PROJ-1234_unsubscribe_link_for_newsletters") определять её идентификатор, идти в Issue Tracking систему и получать название задачи, после чего вставлять его в качестве префикса к сообщению, т.е.:


git commit -m "Some fix"
==> "Необходимо сделать ссылку на отписку от подписок [PROJ-1234] Some fix"

https://github.com/FroMage/git-jira Вот неплохая фича, можно управлять жирой из гита

В будующем планировалось добавить туда проверку докстрингов (процентное соотношение документации к коду, либо какие-либо другие метрики)

Вот что можно использовать Docstring coverage — покрытие python-кода документацией (репозиторий)!

Для приведения кода к pep8 можно использовать autopep8

Для Windows решение - http://plutov.by/post/git_pre_commit_windows

Оставьте свой комментарий

Markdown