Обеспечение соблюдения стандартов кода в git до фиксации

Хорошо, вот сценарий: команда разработчиков хочет, чтобы весь новый код соответствовал определенным стандартам кодирования, и все модульные тесты проходят до принятия фиксации. Здесь трюк, все тесты должны выполняться на специализированной тестовой машине, и у нас нет доступа к модификации сервера git, поэтому это нужно сделать, используя локальный фиксатор фиксации на каждой машине dev.

Хотя спецификации довольно строгие (например, мы не переключаемся на окна или подрывную деятельность), это проблема реального мира, поэтому существует определенная гибкость, если у вас есть решение, которое почти подходит.

  • Мы используем git и * nix.
  • Обновленный код должен быть отправлен на другой сервер для запуска набора тестов.
  • Необходимо указать список измененных файлов, чтобы убедиться, что они соответствуют стандарту кодирования.
  • Его довольно большая база кода, поэтому мы должны отправить наименьший объем информации, необходимой для обеспечения идентичных копий кодовой базы.
  • Если тесты не выдаются, сообщение должно отображаться с ошибкой, и фиксация должна быть заблокирована.
  • Предположим, мы доверяем нашей команде разработчиков, и все в порядке, чтобы тесты можно было обойти с помощью опции --no-verify.

Вопрос: Каков наилучший способ заставить тестовый сервер синхронизироваться с локальной средой для запуска тестов? Какой-то хэш-хэш, соответствующий патчу git для нового коммита? Пропустить git в целом и просто сделать rsync? Что-то еще вообще?

Обновление 8/7/13: Я выстрелил себе в ногу, даже упомянув дистанционное репо. Дело в том, что нельзя блокировать код, который будет перенаправлен на общий/удаленный репо, для предотвращения локального коммита. Независимо от того, считается ли это лучшей практикой, дело не в этом, так как это характерно для небольшой группы разработчиков, которым всем нужна эта точная функциональность. Вопрос в том, как лучше всего достичь цели.

ОТВЕТЫ

Ответ 1

Добавьте пользовательскую команду git, которая:

  • Временно выполняет фиксацию
  • Отбрасывает его на удаленный сервер
  • Запускает тесты (используя сервер CI, post-receive hook или ssh)
  • Возвращает фиксацию, если тесты терпят неудачу

Создайте исполняемый файл с именем git-test-n-commit и поместите его в свой путь:

#!/bin/bash
echo "Committing results..."
git commit "[email protected]"
echo "Pushing to remote testing server..."
git push remote-server-git-url remote-branch -f
echo "Running tests"
ssh remote-server 'cd my_repo; run-my-tests' || 
   (echo "Tests failed, undoing commit" && git reset HEAD^)

Затем вместо вызова git commit ARGS разработчики могут вызвать git test-n-commit ARGS. Если тесты пройдут, код останется зафиксированным. Если тесты потерпят неудачу, это будет так, как будто это никогда не было совершено.

Ответ 2

Локальные фиксации фиксации определенно не то, что вы хотите здесь.

Ваше требование о том, что "у нас нет доступа для изменения сервера git, поэтому это должно быть сделано с использованием локального фиксации фиксации на каждой машине для разработчиков", является полностью фиктивным. Вы всегда можете настроить другой репозиторий, который является вашим "тестовым удаленным", с которым вы полностью контролируете (который затем будет синхронизироваться с сервером git, на который у вас нет контроля).

Как только вы настроите этот тестовый пульт, вы можете добавить крючки для запуска тестов при любом нажатии. Усилие напечатать git push test-remote my-branch для получения результатов теста довольно мало.

Непрерывная интеграция с Git

Также проверьте Jenkins, gitlab и т.д.

Обновление после 8/7/13:

Итак, вы действительно хотите выполнить некоторые "тесты" на удаленном сервере для предотвращения коммитов. Если вы хотите предотвратить использование содержимого самого коммита, используйте pre-commit hook. Посмотрите на этот вопрос, как получить список измененных файлов. После того, как у вас есть эти измененные файлы, вы можете отправить их на удаленный сервер с помощью scp или rsync и запустите тестовую команду с помощью ssh.

Если вам нужно проверить сообщение фиксации, используйте commit-msg hook.

Вот хороший учебник по перехватам: http://git-scm.com/book/en/Customizing-Git-Git-Hooks

В нем также упоминается несколько причин, почему это может быть плохой идеей.

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

Ответ 3

Короткий ответ:

DO NOT

Длинный ответ:

Невозможность совершить фиксацию из-за каких-то странных локальных перехватов кажется мне странной: вам нужно отделить принятие фиксации (т.е. сохранение изменений) от публикации этого коммита.

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

Это было бы контрпродуктивно: люди чувствовали бы себя снова в плохие старые времена, когда им приходилось что-то делать с репо, и каждый мог видеть их ошибки, плохой стиль кодирования и так далее. Вы потеряете свободу, которую дает DVCS: дешевое ветвление, локальная история, сохраняя центральный репо для производственного кода.

Не выполняйте ничего при выполнении локального коммита.

Ответ 4

Я думаю, что лучший подход, который я видел, это git + gerrit + jenkins. Геррит вводит понятие набора изменений. Плагин jenkins gerrit может создавать каждый опубликованный набор изменений (запускать любые типы тестов, которые вы хотели бы) и маркировать их как "проверенные", а затем проверенный набор изменений может быть объединен в главную ветку. Если сборка изменений не работает, коммиттер получает уведомление по электронной почте, затем он может изменить фиксацию и обновить набор изменений.

Ответ 5

После настройки промежуточного сервера, как предложили другие, установите pre-receive, чтобы запустить script по входящей фиксации и нормализовать ее в соответствии со стандартами кодирования. Часто стандарты кодирования определяются правилами, обеспечивающими компьютер. Не делайте, чтобы ваши разработчики обходились с помощью tweaking whitespace hither и tither при простом bash script или что-то в этом роде для них. И если у вас есть script, чтобы сделать это, зачем разработчик запускать его вручную, когда он может запускаться автоматически на каждом push на промежуточное репо.

Ответ 6

Напишите файл Makefile, который:

  • Копирует текущие файлы на тестовый сервер.

  • Находит результаты модульных тестов.

2,1. Если аномалий нет, запустите 'git commit'

2.2 Если есть аномалии, произнесите ошибку.

Использование Make файлов для выполнения компиляции и коммитов - это находка. Я могу автоматизировать сложное форматирование и очистку файлов перед фиксацией.

Edit:

Конечно, Makefile - это не единственное, что вы можете сделать. Ant/Bash/другие языки сценариев могут сделать это для вас.