Да, он написан на питоне, а не на расте, но на что только не пойдёшь ради чистого и собирающегося кода, можно даже переквалифицироваться из питон-разработчка в раст-разработчика. Делаем pre-commit install - это создаёт хук .git/hooks/pre-commit, который будет впоследствии автоматически запускать pre-commit run на изменённые файлы. Делаем pre-commit sample-config > .pre-commit-config.yaml - это создаёт конфиг с набором дефолтных хуков, которыми pre-commit "из коробки" готов проверять изменённые файлы:
trailing-whitespace будет ругаться на строчки, оканчивающиеся пробелами, и эти пробелы стирать. Полезно, потому что не во всех редакторах это включено по-умолчанию, или вообще присутствует как класс.
end-of-line-fixer будет ругаться, если в каком-то файле забыли добавить \n в конец (привет винда!), или наоборот насовали слишком много \n\n\n\n - и тоже добавлять-стирать нужное.
check-yaml будет проверять изменённые в коммите YAML-файлы на синтаксическую корректность.
check-added-large-files будет давать по шапке за попытку закоммитить в репозиторий бинарный суп на 10+ мегабайт - для такого боги даровали нам Git-LFS, Artifactory, Nexus или простихоспаде файлопомойки вроде SFTP/NFS/SMB.
Если хочется ещё - можно докинуть в список, например, check-merge-conflict - оно не даст случайно добавить в коммит "сломаный" после неудачного мержа файл с кучей >>> === <<<. Если что-то кажется лишним - можно убрать.
2. Подключаем "плагин" для проверки проектов на Rust.
На изкоробочном функционале далеко не уедешь - да это и не требуется, поскольку pre-commit рассчитан на активное переиспользование чужого кода с гитхаба:
(содержимое репозитория pre-commit-rust настолько тривиально, что его можно было бы переписать с нуля - но пока более интересна сама возможность с лёгкостью притащить чужое)
Чем это отличается от описанного в статье (помимо отсутствия cargo test)? Тремя важными нюансами:
pre-commit работает только с изменениями, претендующими на коммит. Если часть изменений в main.rs добавлена в staged, а часть нет - из-за интерактивного git add, или вы просто дописали в файл что-то новенькое после стейджа - pre-commit автоматически спрячет "лишнее" через git stash. Это позволяет избежать дурацких ситуаций, когда текущий файл сам по себе норм - но в стейдж например забыли добавить блок с новой функцией.
Автор в хуке делает леденящее cargo fmt && git add ., которое не только похерит возможность использования git add --interactive (как уже писали выше), но и будет добавлять в коммит остальные файлы из рабочей директории, даже если вы их не помечали через git add. В свою очередь, pre-commit после git stash считает хук провалившимся как если он вернул ненулевой код, так и если после работы хука в репозитории появились not staged файлы - это именно то, что мы имеем с cargo fmt.
Большая часть хуков в pre-commit срабатывают только на изменённые файлы определённого типа. Так, хук fmt дёргает cargo fmt -- <changed rust files>: это означает, что во-первых, если форматирование поехало где-то в другой части проекта, ложно-положительных ошибок мы не получим, а во-вторых, если в коммите не трогается код на расте (а например редактируется сугубо README.md - то и растовские хуки срабатывать не будут. Справедливости ради, cargo check и cargo clippy не имеют режима анализа только одного файла - так что с ними проверка будет "полная".
3. Добавляем в pre-commit собственные хуки.
Если нам позарез хочется перед каждым коммитом запускать тесты, выполнять полноценную сборку, вызывать сотону или делать другие нестандартные вещи - pre-commit вполне поддерживает написание собственных хуков:
- repo: local
hooks:
- id: cargo-test
name: run Rust tests
description: Why not?
entry: cargo test
language: system
types: [rust]
pass_filenames: false
Хоп, и теперь он будет вызывать содержимое entry как обычный процесс (благодаря language=system) всякий раз, когда в потенциальном коммите изменяются rust-файлы. Вместо types: [rust] можно также указать files: <regex>. По умолчанию pre-commmit передаёт в хук пути до изменённых файлов - но в нашем случае cargo test some/changed/file.rs просто скажет, что running 0 tests, test result: ok. 0 passed; 0 failed; 3 filtered out; поэтому мы велим вызывать команду как она есть, не скармливая в неё файлы. Аналогично можно будет запускать какой-нибудь самописный tools/linter.sh, который припасён у вас в репозитории.
Большинство плагинов для pre-commit пишутся из расчёта на то, чтобы вызываться pre, собственно, commit - но сама тулза поддерживает ещё и pre-rebase, pre-push и так далее. Если у вас слишком много тестов, их можно вызывать только перед пушем - для этого в описание хука надо добавить stages: [push] (работает и для изкоробочных, и для сторонних, и для локальных хуков), а в самое начало конфига рядом с repos: - добавить default_install_hook_types: [pre-commit, pre-push] и вызвать pre-commit install ещё разок.
4. Добавляем pre-commit в CI.
Хуки в гите работают на доверии и добровольческой основе. Любой зашедший с улицы Васян после git clone получит чистую папку .git/hooks/ и сможет радостно коммитить несобирающийся код с лишними пробелами и переносами строк. И даже если пан Васян соизволят вызвать у себя pre-commit install для инициализации .git/hooks/pre-commit, это не помешает им позже сказать "у меня лапки!" и сделать git commit --no-verify, послав далеко и надолго простыню непонятных ошибок. Едиинственное, что остановит Васяна - разработка через пулл-реквесты и правильно настроенная система Continuous Integration.
Самый простой вариант - иметь один и тот же набор проверок и "на клиенте" и "на сервере". Благо pre-commit может запускаться не только на списке файлов из staged, но и на всех файлах целиком pre-commit run --all-files), и даже на изменённых файлах из указанного промежутка между коммитами (pre-commit run --from-ref=... --to-ref=.... На условном Github Actions это можно сделать так:
name: pre-commit
on:
push:
branches: [ "main" ]
pull_request:
branches: [ "main" ]
env:
CARGO_TERM_COLOR: always
jobs:
lint:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: pre-commit linters
run: |
set -ex
pip install pre-commit
# github does not have branch names, but BASE_REF is a name, not a commit SHA
git fetch
if [ -n "$GITHUB_BASE_REF" ]; then
# this is a PR - check only changed files
pre-commit run \
--verbose \
--show-diff-on-failure \
--from-ref=${{ github.event.pull_request.base.sha }} \
--to-ref=${{ github.event.pull_request.head.sha }}
else
# this is a push to main - check everything
pre-commit run \
--verbose \
--show-diff-on-failure \
--all-files
fi
Это не значит, что ваш CI всегда должен плясать от pre-commit; о "правильной настройке" CI, особенно на больших проектах, можно вообще писать статьи и книги. Просто любая автоматизация проверок будет лучше, чем никакой автоматизации.
Люблю в таких случаях вспоминать свое очное собеседование в один московский магазин электрониники. Там тоже был психологический тест на 300 вопросов — сидишь, кликаешь на эти повторяющиеся "я скорее Х чем У", а рядом сидят кликают еще десяток кандидатов в менеджеры, продавцы, техники, аналитики… А когда все прокликано, тебе рассказывают, что у нас учет времени на рабочем месте по карточкам (не в офисе в целом, а в кабинете, карл!), и доступ в интернет запрещается, и никаких мобильников на рабочем месте, у нас все строго. Шел 2017й год, собеседование на разработчика С++...
В поддержку podsvirov, ответ одного из разработчиков симейка:
It is worth pointing out that many of the findings are actually the in 3rd-party libraries libuv, libcurl, rhash, and libarchive. Especially the last one seems to contribute many issues. You might want to analyze this one next?
The remaining issues come from CTest, CPack, and the Visual Studio specific code. I am surprised the the core of CMake is actually pretty clean.
Это же просто чиселка, на которую можно ориентироваться, да? Вы же не хотите сказать, что если бы мне через неделю стукнуло 24, то дешёвый билет я бы купить не смог, при абсолютной их идентичности?
Что такое коропративный доступ к вскоду?
Как его заблокируют?
Без сарказма, мне реально любопытно.
Начинание отличное, но зачем же останавливаться на полпути? ?
1. Берём pre-commit.
Да, он написан на питоне, а не на расте, но на что только не пойдёшь ради чистого и собирающегося кода,
можно даже переквалифицироваться из питон-разработчка в раст-разработчика.Делаем
pre-commit install- это создаёт хук.git/hooks/pre-commit, который будет впоследствии автоматически запускатьpre-commit runна изменённые файлы.Делаем
pre-commit sample-config > .pre-commit-config.yaml- это создаёт конфиг с набором дефолтных хуков, которымиpre-commit"из коробки" готов проверять изменённые файлы:trailing-whitespaceбудет ругаться на строчки, оканчивающиеся пробелами, и эти пробелы стирать. Полезно, потому что не во всех редакторах это включено по-умолчанию, или вообще присутствует как класс.end-of-line-fixerбудет ругаться, если в каком-то файле забыли добавить\nв конец (привет винда!), или наоборот насовали слишком много\n\n\n\n- и тоже добавлять-стирать нужное.check-yamlбудет проверять изменённые в коммите YAML-файлы на синтаксическую корректность.check-added-large-filesбудет давать по шапке за попытку закоммитить в репозиторий бинарный суп на 10+ мегабайт - для такого боги даровали нам Git-LFS, Artifactory, Nexus или простихоспаде файлопомойки вроде SFTP/NFS/SMB.Если хочется ещё - можно докинуть в список, например,
check-merge-conflict- оно не даст случайно добавить в коммит "сломаный" после неудачного мержа файл с кучей>>> === <<<.Если что-то кажется лишним - можно убрать.
2. Подключаем "плагин" для проверки проектов на Rust.
На изкоробочном функционале далеко не уедешь - да это и не требуется, поскольку pre-commit рассчитан на активное переиспользование чужого кода с гитхаба:
(содержимое репозитория
pre-commit-rustнастолько тривиально, что его можно было бы переписать с нуля - но пока более интересна сама возможность с лёгкостью притащить чужое)Чем это отличается от описанного в статье (помимо отсутствия
cargo test)? Тремя важными нюансами:pre-commit работает только с изменениями, претендующими на коммит. Если часть изменений в
main.rsдобавлена в staged, а часть нет - из-за интерактивногоgit add, или вы просто дописали в файл что-то новенькое после стейджа - pre-commit автоматически спрячет "лишнее" черезgit stash. Это позволяет избежать дурацких ситуаций, когда текущий файл сам по себе норм - но в стейдж например забыли добавить блок с новой функцией.Автор в хуке делает леденящее
cargo fmt && git add ., которое не только похерит возможность использованияgit add --interactive(как уже писали выше), но и будет добавлять в коммит остальные файлы из рабочей директории, даже если вы их не помечали черезgit add. В свою очередь, pre-commit послеgit stashсчитает хук провалившимся как если он вернул ненулевой код, так и если после работы хука в репозитории появились not staged файлы - это именно то, что мы имеем сcargo fmt.Большая часть хуков в pre-commit срабатывают только на изменённые файлы определённого типа. Так, хук
fmtдёргаетcargo fmt -- <changed rust files>: это означает, что во-первых, если форматирование поехало где-то в другой части проекта, ложно-положительных ошибок мы не получим, а во-вторых, если в коммите не трогается код на расте (а например редактируется сугубоREADME.md- то и растовские хуки срабатывать не будут. Справедливости ради,cargo checkиcargo clippyне имеют режима анализа только одного файла - так что с ними проверка будет "полная".3. Добавляем в pre-commit собственные хуки.
Если нам позарез хочется перед каждым коммитом запускать тесты, выполнять полноценную сборку, вызывать сотону или делать другие нестандартные вещи - pre-commit вполне поддерживает написание собственных хуков:
Хоп, и теперь он будет вызывать содержимое
entryкак обычный процесс (благодаря language=system) всякий раз, когда в потенциальном коммите изменяются rust-файлы. Вместоtypes: [rust]можно также указатьfiles: <regex>.По умолчанию pre-commmit передаёт в хук пути до изменённых файлов - но в нашем случае
cargo test some/changed/file.rsпросто скажет, чтоrunning 0 tests, test result: ok. 0 passed; 0 failed; 3 filtered out; поэтому мы велим вызывать команду как она есть, не скармливая в неё файлы.Аналогично можно будет запускать какой-нибудь самописный
tools/linter.sh, который припасён у вас в репозитории.Большинство плагинов для pre-commit пишутся из расчёта на то, чтобы вызываться pre, собственно, commit - но сама тулза поддерживает ещё и pre-rebase, pre-push и так далее. Если у вас слишком много тестов, их можно вызывать только перед пушем - для этого в описание хука надо добавить
stages: [push](работает и для изкоробочных, и для сторонних, и для локальных хуков), а в самое начало конфига рядом сrepos:- добавитьdefault_install_hook_types: [pre-commit, pre-push]и вызватьpre-commit installещё разок.4. Добавляем pre-commit в CI.
Хуки в гите работают на доверии и добровольческой основе. Любой зашедший с улицы Васян после
git cloneполучит чистую папку.git/hooks/и сможет радостно коммитить несобирающийся код с лишними пробелами и переносами строк. И даже если пан Васян соизволят вызвать у себяpre-commit installдля инициализации.git/hooks/pre-commit, это не помешает им позже сказать "у меня лапки!" и сделатьgit commit --no-verify, послав далеко и надолго простыню непонятных ошибок. Едиинственное, что остановит Васяна - разработка через пулл-реквесты и правильно настроенная система Continuous Integration.Самый простой вариант - иметь один и тот же набор проверок и "на клиенте" и "на сервере". Благо pre-commit может запускаться не только на списке файлов из staged, но и на всех файлах целиком
pre-commit run --all-files), и даже на изменённых файлах из указанного промежутка между коммитами (pre-commit run --from-ref=... --to-ref=....На условном Github Actions это можно сделать так:
Это не значит, что ваш CI всегда должен плясать от pre-commit; о "правильной настройке" CI, особенно на больших проектах, можно вообще писать статьи и книги. Просто любая автоматизация проверок будет лучше, чем никакой автоматизации.
английская 'x', да
Люблю в таких случаях вспоминать свое очное собеседование в один московский магазин электрониники. Там тоже был психологический тест на 300 вопросов — сидишь, кликаешь на эти повторяющиеся "я скорее Х чем У", а рядом сидят кликают еще десяток кандидатов в менеджеры, продавцы, техники, аналитики… А когда все прокликано, тебе рассказывают, что у нас учет времени на рабочем месте по карточкам (не в офисе в целом, а в кабинете, карл!), и доступ в интернет запрещается, и никаких мобильников на рабочем месте, у нас все строго. Шел 2017й год, собеседование на разработчика С++...
В поддержку podsvirov, ответ одного из разработчиков симейка:
Это же просто чиселка, на которую можно ориентироваться, да? Вы же не хотите сказать, что если бы мне через неделю стукнуло 24, то дешёвый билет я бы купить не смог, при абсолютной их идентичности?