Перехватчики запросов Github, статический анализ кода и временный откат
Github предоставляет
- перехватывает настройку скриптов, запускаемых при каждом запросе на включение (где, скажем, можно вызвать простой скрипт статического анализатора кода)
- и положение об отклонении запроса на получение, основанное на результатах этого сценария, выполняемого через обработчик запросов на получение.
Я пытаюсь настроить механизм предварительной проверки, чтобы поймать тривиальные ошибки / ошибки, чтобы рецензенты не беспокоились о тривиальных ошибках и могли бы больше сосредоточиться на логике / функции. И если сценарий предварительного просмотра обнаружит, что рассматриваемый источник не соответствует нормам (как правило, когда даже самые простые проверки не пройдены; например, функция с>5000 SLoC или небезопасный strcpy(), или включение устаревших заголовочных файлов и т. Д.), он должен возвращать ошибку, а сам запрос на получение ответа должен давать сбой, если не соблюдены минимальные критерии стробирования.
Так как код находится на github, а не на локальном сервере, это выглядит довольно сложно.
Я получил несколько указателей ( здесь и здесь), но все еще не мог собрать детали полностью. Кодовая база состоит из нескольких репозиториев на github. Есть ли лучший способ добиться этого? Пожалуйста, поделитесь своими мыслями о возможных подходах. Спасибо!
2 ответа
Предоставляет ли GitHub хуки для настройки скриптов, запускаемых при каждом запросе на извлечение (где, скажем, можно вызвать простой сценарий статического анализатора кода), и предоставляет возможность отклонить запрос на извлечение, основываясь на результатах этого сценария, выполненного с помощью перехвата запросов на извлечение.
Это должно быть достигнуто с помощью GitHub Apis, объединяя создание ловушки для событий типа pull_request, а затем декорируя коммиты с результирующим статусом.
Это довольно низкоуровневый подход, но он позволяет вам полностью контролировать то, что делается. Например, вы можете автоматически добавлять комментарии к запросам извлечения или даже закрывать их, если они не проходят процесс анализа.
Другим подходом более высокого уровня может быть использование сервисов Travis CI путем добавления файла .travis.yml в ваш репозиторий. Трэвис является бесплатным для проектов с открытым исходным кодом, а также предлагает платные услуги для частных репозиториев.
Настроить Travis довольно просто, а настройка скрипта сборки очень проста.
Ниже приведены два примера сценария Travis для вашего вдохновения:
- LibGit2: библиотека C Сборка с несколькими компиляторами, запуск тестов, запуск Valgrind. Сборка завершается неудачно (и PR оформляется как таковой), когда код не компилируется или при сбое теста.
- LibGit2Sharp: привязка A C# для LibGit2. Сборка с использованием компилятора Mono Xbuild, запуск тестов. Сборка завершается неудачно (и PR оформляется как таковой), когда код не компилируется или при сбое теста.
Официальный анонс сервисов GitHub Commit Status можно прочитать в этом блоге.
Вы можете использовать для этого: https://github.com/tomasbjerre/violation-comments-to-github-lib
Он проанализирует файловую систему, чтобы найти файлы отчетов из статических анализаторов кода, а затем использует их для комментирования запроса на загрузку в GitHub.
