Как настроить форматирование, линтинг, запуск тестов локально?
Если Вы используете git, то для этого есть git hooks, которые позволяют выполнять кастомные действия перед коммитом, после коммита и т.п. Примеры таких хуков есть в любом git репозитории в папке .git/hooks.
Для использования в git hooks есть известная библиотека, которая называется Husky. Наиболее популярна её версия написанная на js. Но мы будем использовать её порт под .NET.
Почему именно Husky.NET? Потому что мы пишем проект на .NET, а значит у разработчика .NET SDK/runtime точно установлен и ничего дополнительно ставить не придется, как в случае с оригинальной Husky (там нужен npm/yarn и node.js)
Husky конфигурируется достаточно просто (ссылка на оф. гайд)
И для наглядности вот так я подключил её к проекту BookLibrary.
В Husky можно объявлять tasks. По сути это список задач которые будут запускать те или иные команды. Например dotnet build.
Задачи можно группировать и тем самым запускать несколько команд вместе в порядке их объявления в tasks.
Обратите внимание на группу pre-commit. Эта группа будет запускаться командой через git pre-commit hook еще до создания самого коммита:
dotnet husky run -v --group "pre-commit"
А это означает, что мы можем и не позволить этого сделать если найдем какие-то ошибки. Например проект не билдится, тесты не проходят.
В нём же можем автоматически отформатировать код измененных *.cs файлов или просто убедиться что форматирование не требуется.
Можем проверять размеры файлов и типы, чтобы не захламляли большими файлами, запустить SAST анализ, чтобы случайно не закоммитили секреты и много разного интересного :)
Окей, теперь у нас проект точно билдится, тесты проходят и отформатировано согласно код стайлам.
Теперь хорошо бы чтобы все разработчики использовали conventional commits, для того чтобы использовать их для автоматического версионирования и возможности генерировать по ним красивый changelog, который можно опубликовать вместе с NuGet пакетом или например в рабочий чат в качестве уведомления о релизе.
С этим нам поможет git commit-msg hook, который будет запускать команду:
dotnet husky run -v --group "commit-msg" --args "$1"
В качестве аргумента здесь передается текст коммита и проверяется с помощью C# скрипта, который запускается тут.
Он проверяет, что коммит соответствует конвенциям. А если у Вас принято указывать номер задачи в Jira, то позволять указывать и его как scope.
Например:
feat(BKL-1402): Подключен линтер
Для версионирования и генерации changelog можно использовать например versionize.
P.S. все это можно сделать и без Husky, написав необходимые вызовы в файлах хуков
Если Вы используете git, то для этого есть git hooks, которые позволяют выполнять кастомные действия перед коммитом, после коммита и т.п. Примеры таких хуков есть в любом git репозитории в папке .git/hooks.
Для использования в git hooks есть известная библиотека, которая называется Husky. Наиболее популярна её версия написанная на js. Но мы будем использовать её порт под .NET.
Почему именно Husky.NET? Потому что мы пишем проект на .NET, а значит у разработчика .NET SDK/runtime точно установлен и ничего дополнительно ставить не придется, как в случае с оригинальной Husky (там нужен npm/yarn и node.js)
Husky конфигурируется достаточно просто (ссылка на оф. гайд)
И для наглядности вот так я подключил её к проекту BookLibrary.
В Husky можно объявлять tasks. По сути это список задач которые будут запускать те или иные команды. Например dotnet build.
Задачи можно группировать и тем самым запускать несколько команд вместе в порядке их объявления в tasks.
Обратите внимание на группу pre-commit. Эта группа будет запускаться командой через git pre-commit hook еще до создания самого коммита:
dotnet husky run -v --group "pre-commit"
А это означает, что мы можем и не позволить этого сделать если найдем какие-то ошибки. Например проект не билдится, тесты не проходят.
В нём же можем автоматически отформатировать код измененных *.cs файлов или просто убедиться что форматирование не требуется.
Можем проверять размеры файлов и типы, чтобы не захламляли большими файлами, запустить SAST анализ, чтобы случайно не закоммитили секреты и много разного интересного :)
Окей, теперь у нас проект точно билдится, тесты проходят и отформатировано согласно код стайлам.
Теперь хорошо бы чтобы все разработчики использовали conventional commits, для того чтобы использовать их для автоматического версионирования и возможности генерировать по ним красивый changelog, который можно опубликовать вместе с NuGet пакетом или например в рабочий чат в качестве уведомления о релизе.
С этим нам поможет git commit-msg hook, который будет запускать команду:
dotnet husky run -v --group "commit-msg" --args "$1"
В качестве аргумента здесь передается текст коммита и проверяется с помощью C# скрипта, который запускается тут.
Он проверяет, что коммит соответствует конвенциям. А если у Вас принято указывать номер задачи в Jira, то позволять указывать и его как scope.
Например:
feat(BKL-1402): Подключен линтер
Для версионирования и генерации changelog можно использовать например versionize.
P.S. все это можно сделать и без Husky, написав необходимые вызовы в файлах хуков